Разрозненные мысли о тестировании.
Подходы пропагандируемые в TDD, и то что многое считают Unit тестами - это разные вещи. В Test Driven Development - тесты это способ мышления, нельзя создать программу не написав тесты. Писать тесты до написания кода - легко, писать unit тесты после - скучно, бессмысленно и зачастую невозможно.
Тесты всякие нужны, тесты всякие важны.
В традиционном TDD потери времени на написание тестов нет по определению.
Думать тестами я не привык. Можно предположить что многим это тоже тяжело.
Возможностью автоматизированного тестирования <= Низкая связность <= Хорошая архитектура. Обратная цепочка, тоже зачастую имеет место быть.
Оценивать связность с точки зрения тестов проще.
Для раннего обнаружения проблем тесты не обязаны тестировать все. Сразу не обнаруженная сложная ошибка в нижнем уровне, как снежный ком - лавиной обрушит самые банальные тесты верхнего. Но перед исправлением, тест придется все-таки написать :).
Тесты документируют ошибки. Написал тест, исправил, прогнал тест - гарантия что на эти грабли больше не наступишь не только ты но и твои товарищи (Особенно важно при рефакторинге).
Рефакторинг без тестов <=> Сам себе злобный буратина.
Сделал рефакторинг, не компилируется тест - повод сообщить об изменениях и способах переноса старого кода друзьям по команде.
Пре и пост условия - это не автоматизированные тесты (ударение делать на любое слово по вкусу). К ним все равно необходим набор автоматических сценариев.
В отличие от самопальных решений, unit тесты - это отраслевой стандарт оформления автоматических сценариев. Для них есть поддержка со стороны IDE.
Тесты автоматизируют труд разработчика, дополняя своей специфичной функциональностью IDE. Тесты подсвечивают места ошибок. Тесты упрощают дебаг. Один клик и ты в месте проблемы.
Нет хорошего кода, есть код который легко переписать. Тесты один из путей достижения легкости.
В Lingvo есть отдельная статья - "Легкотестируемый - Easy-to-test"
Крылья, ноги - главное мозги, все равно тесты не гарантируют успеха.
Четыре больших буквы IMHO перед каждым безапелляционным утверждением касающегося разработки программного обеспечения, можно опускать только в своем личном ЖЖ.
Тесты всякие нужны, тесты всякие важны.
В традиционном TDD потери времени на написание тестов нет по определению.
Думать тестами я не привык. Можно предположить что многим это тоже тяжело.
Возможностью автоматизированного тестирования <= Низкая связность <= Хорошая архитектура. Обратная цепочка, тоже зачастую имеет место быть.
Оценивать связность с точки зрения тестов проще.
Для раннего обнаружения проблем тесты не обязаны тестировать все. Сразу не обнаруженная сложная ошибка в нижнем уровне, как снежный ком - лавиной обрушит самые банальные тесты верхнего. Но перед исправлением, тест придется все-таки написать :).
Тесты документируют ошибки. Написал тест, исправил, прогнал тест - гарантия что на эти грабли больше не наступишь не только ты но и твои товарищи (Особенно важно при рефакторинге).
Рефакторинг без тестов <=> Сам себе злобный буратина.
Сделал рефакторинг, не компилируется тест - повод сообщить об изменениях и способах переноса старого кода друзьям по команде.
Пре и пост условия - это не автоматизированные тесты (ударение делать на любое слово по вкусу). К ним все равно необходим набор автоматических сценариев.
В отличие от самопальных решений, unit тесты - это отраслевой стандарт оформления автоматических сценариев. Для них есть поддержка со стороны IDE.
Тесты автоматизируют труд разработчика, дополняя своей специфичной функциональностью IDE. Тесты подсвечивают места ошибок. Тесты упрощают дебаг. Один клик и ты в месте проблемы.
Нет хорошего кода, есть код который легко переписать. Тесты один из путей достижения легкости.
В Lingvo есть отдельная статья - "Легкотестируемый - Easy-to-test"
Крылья, ноги - главное мозги, все равно тесты не гарантируют успеха.
Четыре больших буквы IMHO перед каждым безапелляционным утверждением касающегося разработки программного обеспечения, можно опускать только в своем личном ЖЖ.