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

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

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

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

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

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

G>>>>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
AVK>>>Интеграционные тесты не делаются для отдельного модуля. По определению.
G>>Да, они делаются для модуля и некоторого подмножества связанных с ним. Обычно для самого модуля+вызываемых модулей из низлежащих слоев.
N>Для меня это будет называться, скорее всего, функциональными тестами (а интеграционными будут проверки суммарной функциональности нескольких крупных блоков, не подчинённых друг другу, а работающими совместно).

Без разницы совершенно как оно будет называться.

Функциональные тесты — это тесты которые тестируют функционал, они бывают unit-тестами, которые тестируют один модуль в изоляции от других и интеграционными тестами, которые тестируют несколько модулей в связке.

Я обычно такой терминологией пользуюсь, но если вам удобно используйте любую другую.