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

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

IT>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.

MS>А так же противоречит первой заповеди программиста, "не навреди".

Предпочитаю активный code-review в течении всего времени разработки проекта.

Полностью полагаться на юнит-тестинг и другой тестинг не могу, это ненадежно в принципе. Даже сами исходники юнит-тестов должны так же подвергаться постоянному review.

Основная проблема, которую замечаю у ребят при разработке юнит-тестов, что то, что юнит-тесты зачастую направлены на тестирование функциональности, а не кода.

Код обычно гораздо богаче своей основной функциональности. Методология "тесты вперед" выглядит красиво, но должна использоваться аккуратно, ибо не обыгрывает все возможные варианты реальной имплементации. Самые последние тесты должны быть написаны по зеркальной методологии "тесты назад" , и должны проходить абсолютно по всем веткам исходников, т.е. в принципе должны быть написаны отталкиваясь от исходников.

Ввиду того, что полное покрытие кода юнит-тестами потенциально может отнять в несколько раз (во много раз) больше трудоемкости, чем сама разработка системы, придпочитаю комбинированный подход: code review и "сплошной" юнит тестинг (местами )

Акценты расставляются так: чем выше уровень задачи, тем более "сплошным" должно быть покрытие юнит-тестами, т.е. юнит-тесты под прикладную часть пишутся отталкиваясь от кода, и обязаны покрыть все ветки всех алгоритмов. Чем ниже уровень, тем более юнит-тесты близки к функциональным и тем жестче code-review. В этой области рулят методологии, далекие от eXtreme. Жесткая дисциплина проектирования и т.д.

--------

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