afgmНе все могу позволить себе тестеров, не говоря уже о полноценном ТЗ, TDD подходе и прочих вещах.Тестеры и ТЗ - это внешние вещи. А кто мешает использовать TDD или хотя бы покрывать юнит-тестами наиболее критичные участки? Это внутреняя кухня программиста, и никто кроме него самого, его лени/привычки тут не будет преградой.

p.s. Кто-нибудь использует юнит-тестирование хранимых процедур? Изобретаю свой велосипед для их разработки, хранения в БД и автозапуска. Но быть может всё уже апробировано до нас? Применительно к Firebird, конечно.

eXandr,

Превышение всех мыслимых сроков на подготовку релиза 3.0 чем не аргумент?
Сабжевая фича нисколь не критична (не спорю - может быть полезной, но не критична), поэтому не уделять время на её кодирование и тестирование в условиях ахтунга по срокам - вполне логично.

afgmнаш продук внутренний. И на этот продукт внутренней автоматизации работает отдел. Писать тесты по времени раза в 2, в случашем случае, дольше чем реализовывать сам алгоритм, а мы только и поспеваем соответствовать предъявляемым требованиям.Всё верно, но только пока вы больше пишете, чем правите/рафакторите. Как только продукт становится достаточно бородатым, что львиная доля вносимых изменений - это правки существующего кода, отсутствие тестов в разы увеличивает время патчинга. Ну а ежели разработчков более одного и нет четкого разделения ответственности за модули (каждый патчит любой участок), или если у вас значимая текучка девелоперов, то я бы покрывал тестами всё и сразу: отсутствие тестов тут не столько экономия времени, сколько накопление технического долга - рано или поздно вы уйдете в минус.
Глубокое имхо, т.к. сам созрел до тестов всего год назад, но пользу от их наличия (пусть и не по всему коду, а только по ядру системы и разделяемым библиотекам) пожинаю. Рефакторить блоки, покрытые тестами, одно удовольствие.