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

G>>>>>2)Unit-тесты абсолютно нет смысла писать после кода
G>>>>>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
AVK>>>>Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
G>>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее. Как некоторый framework, на основе которого будет строиться приложение.

N>>Здесь AndrewVK более прав: определение стабильной части кода заранее на практике скорее невозможно, а там, где возможно, она уже стабилизировалась давно (и обычно выглядит в виде библиотеки) и требует наличия тестов уже до текущей работы.
G>Практика как раз подтверждает обратное. Ведь существуют кучи фреймворков, может не все удачные, но они есть.

Если ты пользуешься готовым фреймворком, то он отделён и развивается отдельно.
Если ты его создаёшь в процессе развития своего кода выделением из него, он вначале нестабилен.

N>>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
G>И? Одна тонкость не ставит под сомнение существование самих движков.

Она подтверждает AVK: "стабильность участков кода обычно определяется уже после их написания".

G> И уж точно не говорит о том что их нельзя покрывать тестами.

Этого я и не говорю. Но уровень затрат ресурсов на покрытие тестами может и часто должен меняться в зависимости от того, насколько стабилизировались внешние условия и представления об основах реализации. Нет смысла плотно покрывать тестами то, что может завтра быть вынесено к лешим.

N>>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
G>Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит.

Вывод про "только" высосан из пальца.

G> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.

Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
(В самом выдающемся случае можно уже из спецификаций породить тесты по методу quickcheck или PropEr — на случайных данных — и с какой-то вероятностью через некоторое слабопредсказуемое время найти контрпример.)

G> Если вы не видите, то вам они не нужны.

Грубый и бессмысленный наезд. Правильно было бы сказать, что они местами нужны больше, местами — меньше.