Question: Do I need a Unit test or Functional test?
Answer: Yes
(источник)
Без юнит-тестов никак не обойтись и в этом заголовке шутка. На мой пост меня натолкнула заметка Сергея о Как тестировать приватные функции. У него можно найти бесспорный ответ на вопрос как: "Только через публичный контракт этого класса"
Можно ли обойтись без юнит-тестов? Чаще можно ответить да чем нет. Что бы понять ответ достаточно определить о каком коде идет речь:
- Или бизнес-код
- Или инфрастуктура (framework)
Бизнес-код, | Библиотека, | |
Количество зависимого кода | Определено и ограничено | Неопределено и недоступно |
Доступность зависимого кода | Весь код в одном VS-решение | Недоступен |
Окружение | Известное и ограниченное - определенный продукт или inhouse-система | Неограниченное, неопределенное множество. Т.е. зависимый код будет когда-то кем-то написан |
Тестирование | функциональные тесты с помощью инженера по качеству | Юнит-тесты |
Источник знаний о коде | Зависимый код | Юнит-тесты |
Текучесть требований | Высокая изменчивость требований. Модификация кода в соответсвии с изменчивостью требований происходит легко поскольку вся система доступна в коде и любые изменения легко отслеживаются в зависимом коде. | Теоретически изменения возможны только в одном случае: не требуется модификация зависимого кода. Практически новые фичи инфрастуктуры выпускаются новой версией, новым релизом. |
Верификация результатов рефакторинга. | Компиляция кода, регресионные тесты инженером по качеству. | Регрессионные юнит-тесты |
Ну таблица, и что дальше? А дальше - цитата. Brad Abram в одном из своих постов об обновлении Framework Design Guidelines цитирует Фила, разработчика ASP.NET MVC: "Well-Designed Frameworks Are Testable." Мне так и не удалось найти ответ почему?, без которого любой пост становится похож на догму. Но ведь Фил прав! Попробую ответить за Бреда, почему Ваш framework становится хорошим, когда он легко тестируется (unit-тестами):
- Вы всегда знаете, как расширить вашу инфрастуктуру
- Вы всегда уверены в том, как поступить с новыми требованиями к вашей инфрастуктуре
- Вы легко можете научить пользоваться вашей инрастуктурой ваших коллег
- Вы всегда можете дать ответ на пригодность вашей инфрастуктуры в новом окружении
В защиту заголовка:
- Не бывает вопроса как протестировать код
- Не бывает вопроса нужно ли тестировать этот код?
- Не бывает вопроса зачем тестировать код?
