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

B>То, что ты пишешь, это не описание того, что ты делаешь,
B>а описание границ применимости этого вида тестирования.
вот именно. у метода есть границы применимости, и эффективность применения в разных типах проектов. об этом надо помнить, а то получится как с рефакторингом ))

D>>юнит-тесты и обвязка для них пишутся самим программистом. то есть качество тестов <= качество кода.
B>Качество тестов зависит от качества спецификаций модулей.
B>Его (качество) тоже можно контролировать.

D>>юнит-тесты проверяют работу отдельных частей системы, а не их взаимодействие.

B>Конечно unit test не является integration test. Кто-то утверждает обратное?
B>unit test так же не заменит системного и многих других видов тестирования.
будем считать, что договорились?

B>Впрочем я соглашусь, что юнит-тесты, как и любая работа, требует усилий.
B>Качество вообще на шару не получается.
B>Если конкретно в вашем случае польза меньше, чем затраты, то видимо вам это и не нужно...
B>Но мой опыт таков, что внедрение юнит-тестов всегда оправдывало себя.
B>Затраты, на самом деле, не велики, а польза есть.
B>У нас, к примеру, до внедрения юнит-тестов каждый программер все равно писал
B>какие-то тестовые программы, в которых игрался с тем, что он разрабатывает.
B>Т.е. каждый программер все равно создавал свою среду, в которой он мог
B>как-то убедиться в том, что его кусок в целом работает.
B>Внедрение юнит-тестов — это не более чем,
B>внесение порядка и предсказуемости в такую деятельность.
и что, организован процесс автоматического тестирования?