Здравствуйте, Sinix, Вы писали:

S>В реальном бизнес-коде польза от тотального покрытия ещё меньше — самые гадкие ошибки возникают при дичайшем стечении обстоятельств, которое в тестах воспроизвести нереально.
S>Из практики — надёжно работают только ассерты, да и то не всегда. Самый простой пример:
S>

S>    static double Sample(double a, double b, double c)
S>    {
S>        if (a > 1) a = 1;
S>        if (b <= 1) b = 1;

S>        Code.AssertState(a != b, "Some detailed message");
S>        return c / (a - b);
S>    }
S>

S>a, b и c считаются в независимых частях кода, каждая часть — примерно 50-100 строк оттестированного кода с подборкой коэффициентов из кучи шкал. Все мыслимые тесты зелёные, интеграционные — тоже (a != b). Благодаря ассерту всё-таки нашлась ошибка, но уже у клиента.
Что-то это меня тоже не убеждает, скорее наоборот, подтверждает значительность первой буковки D в аббревиатуре TDD. Если пишешь X / Y нужно задуматься, а что будет если Y==0... это один из классических крайних случаев, первый кандидат в юнит-тесты. Притом, раз уж ты догадался ассерт вставить, то лучше вместо ассерта уж лучше придумать такой юнит-тест, который воспроизведёт ситуацию. И в этом юнит-тесте будет сразу видно какая конкретная бизнес-ситуация соответствует этому странному стечению обстоятельств, что тоже поможет найти ошибку, но не у клиента, а на этапе написания кода, ещё до публикации коммитов.
А если получается так, что сложно воспроизвести эту ситуацию из-за кучи шкал и прочих "независимых" (хе-хе) частей кода, значит код говно и надо рефакторить этот юнит-переросток, разбивая его на проще тестируемые мелкие юниты.