Здравствуйте, Poopy Joe, Вы писали:
N>>Вот после этого можно говорить — не абсолютно, но с практически достаточной уверенностью — про отсутствие багов.
PJ>И че хоть раз такое происходило? Ну, только честно.
Постоянно происходит, честно.
Например, QA в очередном релизе отловил 20 багов; у кастомеров сработало ещё 10; перед этим запуском в Jenkins было поймано и исправлено 300-400.
Перед этим ещё 100 (народ достаточно ленив) поймано самими программистами, в варианте "вот я наверно это сломаю... пойду запущу сразу, не дожидаясь получасового прогона всех тестов".
Цифры меняются, соотношение примерно похоже на это.
Ну а так как цена отлова бага на стадии CI в десятки раз меньше такого же на кастомере (не считая потерь самого кастомера), то можно было бы и 95% времени тратить на тесты. Это уже не получается — не организуешь людей на это.
N>>Ну вот я выше и описал. Разница между "ничего не гарантируют" и "статистически гарантируют поиск >90% ошибок", по-твоему, важна или нет?
PJ>Нет, разумеется. Гарантия понятия бинарное, она либо есть, либо ее нет. И нет, тесты этого не гарантируют. Все что гарантируют тесты, это если у тебя измениться поведение функции которую проверяет тест, при условии, что тест проверяет конкретный случай, то он это покажет.
Ну вот пока ты будешь так думать, будешь предельно непрактичен.
И я не зря "подпёр" полезность тестов условием верификации кода.
N>>И да, в это я верю. Как-то практика показывает, что именно так и оно и работает 
PJ>В стране с единорогами?
Реальные проекты, реальные люди со всеми их проблемами.
Просто систему наладили и она кое-как, подпрыгивая на ухабах, но постоянно движется вперёд.
Единорогов не впрягали, за неимением таковых.
N>>Конечно, нет. Может, у тебя один тест, который проверяет, как main() разбирает аргументы, и он зелёный
PJ>Во, ты начинаешь что-то подозревать. Прикол в том, что это ничем не отличается ни от 1000, ни от 10000.
N>>1) Разумность самих тестов (метода, набора тестовых данных), с точки зрения нахождения проблем реализации согласно задаче и выбранному методу.
PJ>И как ты проверяешь разумность?
По каждому случаю отдельно.
Вот пример (не мой): у процессора нет операции умножения, надо её сэмулировать. Делается вариант 16*16->16 с откидыванием старшей части. Знаем, что будет какой-то цикл по битам.
Добавляем тесты: 0*0 -> 0, 1*0 -> 0, 1*1 -> 1, 2*0 -> 0, 0*2 -> 0, 2*2 -> 4, 2*-2 -> -4, -2*2 -> -4, 2*2 -> 4.
Ещё парочку базовых, типа 137*73 -> 10001.
На переполнение: 256*256 -> 0, 257*257 -> 513, -32768*3 -> -32768...
Пара десятков таких тестов покроет и базовую функциональность, и маргинальные случаи, с запасом на все типовые алгоритмы.
N>>2) Верификация кода (хотя бы визуальная) на то, что реализован действительно нужный подход (а не поставлен, грубо говоря, большой if на конкретные тестируемые случаи).
PJ>Жесть какая... 
Что удивляет-то? Никогда peer review не проходил? Ну, всё впереди.
N>>3) Достаточное покрытие нужного-по-ТЗ кода тестами (несмотря на всю условность этого понятия).
PJ>Достаточное это какое?
100% хотя бы одним тестом каждого куска кода основного пути выполнения.
Не считаются те, которые вызываются плохо предсказуемыми внешними условиями, хотя и их можно на следующем круге замокать.
N>>4) Доверие среде и библиотекам.
PJ>А нафига тогда все предыдущие?
Ну мало ли. Вдруг в следующей версии починят?
)
N>>Были, где, грубо говоря, 90%. Сейчас крайне мало — но это потому, что ресурсов нет. А так я бы и сейчас добавил переменных.
PJ>Охотно верю, был демо проект, где 90% и реальный код, где их почти нет. Я ровно об этом.
Это у тебя демо, а у меня был полностью реальный.
N>>Если ты используешь тесты ровно для этого — это твои личные ограничения.
PJ>Увы, не мои. Это ограничение самой методики. Вот честно, хотелось бы иметь волшебную технологию уровня "компилируется — в продакшн"
Ограничения у методики есть, но сильно дальше, чем ты их видишь.
N>>А почему ты в этом рассмотрении предполагаешь только внутренние кодовые тесты?
PJ>Потому что речь о ТDD.
Нет, не только.
PJ> Впрочем, заказчика вообще никакие тесты не интересуют. Я, по-крайней мере, таких не видел.
Ну я видел, и работал с. И ты не учитываешь внутреннего заказчика в продукте.
N>>Это ловится на других уровнях и другими методами.
PJ>Какими?
Да хоть ручной проверкой. Это уже не наша задача.
N>>А кто только что писал про предыдущую спецификацию? Сам уже не помнишь, что писал?
PJ>Я вообще не понял, что ТЫ написал. Я либо впервые использовал слово спецификация, либо использовал его до этого. Оба утверждения твои и оба они не могут быть верными одновременно.
Я про предыдущую спецификацию вроде не писал первый.
N>>OK. Представим себе, что "спецификация" это "полное и точное ТЗ", и пойдём дальше. Так откуда взялась предыдущая спецификация?
PJ>I'm lost. Полное и точное ТЗ, это функциональные требования к системе, это функциональные тесты, в лучшем случае.
PJ>Спецификация о которой идет речь это спецификация на отдельные куски кода, которые ты покрываешь тестами. Представим, что теплое это мягкое и пойдем дальше. 
Ну у тебя почему-то ТЗ это сверху, а спецификация это снизу. Я не вижу причин так делить.
N>>Сарказм понят, но не оценён. Нарвёшься на то, что будешь отказываться от доступных средств из-за гордыни.
PJ>От каких доступных средств я отказываюсь? От тестов? Это ты сам придумал.
PJ>От построения из них карго-культа? Так это ты нарвешься, думая, что они тебе чего-то там гарантируют.
Я получаю с них реальную пользу — баги ловятся задолго до попадания к кастомеру. А ты можешь продолжать искать и требовать воздушные замки.
