Светлый идеал 100% покрытия тестами

[lionet]

Что-то я не понимаю эти вот страдания по поводу того, что покрытие кода не 100%. Ну допустим ваша тулза показывает 100%. Что это значит, можно конюшни больше не чистить? А вот и нет:

int f(int a, int b) {
int arr[2] = { 0, 0 };
int i = 1;

if(a == 1) i--;

if(b == 1) i--;

return arr[i];
}И что это вам дало? Покрытие по строчкам 100%, а

Comments

[dmzlj]

Упало, починили, сделали регрессионный тест, поехали дальше. лучше с покрытием, чем без покрытия.
У нас вот 0% процентов покрытия тестами на текущий момент, на эрланге это больно. И щас вот теряя тапки
побежали прикручивать регрессионные, без них невозможно уже.

[levgem]

ты так говоришь, будто есть какой-то язык программирования на котором отсутствие тестов - это не больно =))

У меня тоже не было тестов в эрливидео, пока кодовая база не начала расти.

[dmzlj]

На х-ле можно очень долго прожить до момента, когда отсутствие тестов станет причинять боль.

[sorhed]

Там можно начать тестировать в любой момент. Функции аккуратны, сайд-эффекты изолированы, красота!

[sorhed]

Ну я не понимаю, как в 2015, блин, году, можно до сих пор писать на не memory-safe языках. C/C++ причинили компьютерной индустрии триллионы убытков, без преувеличений.

(Что, конечно, не отменяет того, что coverage - бессмысленная метрика).

[archaicos]

memory-safe - это только одни грабли, на которые можно наступить. И нужно ещё не забывать, что даже если нельзя добраться до памяти, куда доступ запрещён, остаются исключения, бросаемые по выходу за границы массива и при попытке использования нулевого указателя (привет Java и прочим memory-safe языкам с такими волшебными «указателями» и проверками границ). Как я понимаю, эта проблема не решается в принципе. Если я понимаю неверно или чего-то упустил из виду, просветите.

[dottedmag]

Исключения - это другое дело. Они не решают задачу "как сделать корректную программу", они упрощают задачу "как отлаживать, когда программа некорректна, и мы знаем, в чем это проявляется".

Поясню: в memory-unsafe языке причиной появления неверного значения в переменной потенциально может послужить любая операция, изменяющая состояние памяти. Недостаточно проглядеть только те части, которые меняют соответствующую переменную, необходимо читать или гонять всю программу целиком. В memory-safe языке достаточно посмотреть, что трогает соответствующую переменную, что гораздо проще.

При этом чем ограниченнее возможность раздавать ссылки на переменные вокруг, тем проще отлаживаться (в диапазоне от Java "гуляй рванина" до Haskell'овой монады ST, где мутабельная память инкапсулирована максимально).

[archaicos]

Но мы же наверное хотим не просто более отлаживаемую программу, а более правильную, так? Если исключение никогда не выскакивает у разработчика («А чо, у меня всё работает!») или у тестировщика («У меня все 100500 тестов прошли!»), но периодически ломает всё в боевых действиях, то это та же проблема: код с упущенной ошибкой.

[dottedmag]

Есть теорема, что для любой метрики покрытия тестами можно написать код и входные условия, которые вызовут ошибку, но при этом покрытие будет 100%.

Что не мешает быть покрытию полезным, чтобы смотреть, что вообще не оттестировано. При этом построчное покрытие - слишком грубо. Покрытие по веткам дает более приличный результат.

[nponeccop]

Более того, даже при формально написанной спецификации и коде, 100% соответствующем спецификации (например, проверенном модел чекером), может быть баг в спецификации. Или спецификация написана в соответствии с пониманием разрабом задачи, но понимание неверное.

[sorhed]

Что значит «может быть»? Спецификация всегда несовершенна.

[_winnie]

Есть опечатки такого рода, что если до них дойдет управление - то эти опечатки гарантировано взорвуться и будут замечены.

Покрытие на 100% проверяет, что таких опечаток нет.
Например, такое покрытие гарантирует отсутвие ошибок вида "бля вы это пробовали запустить хотя бы раз после написания", и предотвращает грех "я думал, это такое простое исправление, что можно не проверять".

Это полезно, так как большинство опечаток - именно простые, а не для хитрой комбинации параметров.

Еще покрытие на 100% проверяет, что нет dead code

Ну и да, отличие кода от данных оно искусственное. Еще, даже эквивалентные преобразования кода могут привести к тому, что поменяется покрытие со 100% на другое.

[daedmen]

Эх, давно мечтаю что бы вот это вот "запускали хотя бы раз" можно было автоматом превращать в покрытие тестами….

[jakobz]

Проблема в том, что 84% программистов - не в этой уютной тусовочке, и не в другой аналогичной. Они читают книжки про "Domain Driven Design" и прочих Фаулеров, и совершенно искренне доверяют ихнему авторитету. А они говорят что 100% покрытие тестами - это круто и вообще панацея. То, что их эти авторитеты кидают как лохов - объяснить им очень сложно

[nponeccop]

В том видео про TDD, доведённый до маразма, очень хорошо сказано.

[tonsky]

А Фаулер-то че, вроде адекватный чувак http://martinfowler.com/bliki/TestCoverage.html

[tonsky]

Блин, DDD с TDD перепутал :)