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

C>Пофиг. Юнит-тесты писать проще всего. И по наблюдениям, если юнит-тестов мало, то интеграционных тестов нет вообще.
Написать проще всего — это да. Поддерживать — это вряд ли См ниже.

C>Так это говнокод, однако. Если изменение одного заказчика ломает 100500 тестов, то код или тесты написаны плохо. Думайте как переделать.
Нет. Это на требования одного заказчика приходится писать 100500 тестов, если решать проблему в лоб. Я ж говорю

Она отлично работает для инфраструктуры, почти для любого масштаба, неплохо работает для мелочёвки и абсолютно не работает даже для средних проектов. Чтоб было понятно, что такое средний проект: представь себе типовой биз-кейз в виде 20-страничного документа 12 шрифтом, в котором 90% текста — не вода, а логика, причём высокоуровневая...

Вся переиспользуемая инфраструктура, что ниже, понятное дело, покрыта юнит тестами, т.к. её легко разобрать на запчасти и протестировать по отдельности.

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

Самое эпичное, что попадалось — вычисления с принудительным округлением до то ли 5, то ли 8 знаков после запятой после каждой из операций. Ибо какой-то древний сервис у одного из контрагентов считал именно так и иначе цифры не бились. Реального объяснения так и не добыли, в качестве извинения-байки — цифры подгоняли под ещё более древние бумажные записи, которые велись именно с такой погрешностью.

Ну и про настройку количества байт в мегабайте

Автор: Sinix
Дата: 22.04.15

тоже писал как-то. В общем, это не говнокод. Это реальность такая замечательная


C>Вторые 95% догоняются на этапе интеграционного тестирования.
В общем, об одном и том же говорим, только разными словами. Я ж не утверждаю, что юнит-тесты не нужны Я про то, что ими ограничиваться не надо.