Ограничения модульных тестов |
Некоторые разработчики догматичны в использовании философии разработки через тестирование (TDD). Для MVP я думаю, что это неправильный подход. Здесь я изложу несколько соображений по поводу прочной культуры разработки, пока вы строите свой бизнес. Особое внимание я уделю модульным тестам, тестам, которые проверяют атомарные компоненты приложения.
Преимущества
Покрытие тестами обычно уменьшает количество ошибок. Код более предсказуем и менее загадочен. По большому счету, вы не будете оглянуться на код и сказать: «Я понятия не имею, почему это работает», что на удивление распространено. Это может улучшить структуру кода, заставив вас создавать атомарные методы, которые легко передавать аргументы интерфейса, код приложения лучше организован для понимания. Это делает его более надежным и понятным для новых инженеров. Написание в строгом TDD может прояснить требования на более ранних этапах процесса, потому что TDD утверждает, что тесты пишутся до кода приложения, и поэтому функциональность проясняется до того, как тратить время на написание. Покрытие тестами может быть значимой метрикой, но потенциально метрикой тщеславия для третьих сторон, чтобы получить поддержку с «95% тестовым покрытием».
Недостатки
Время и энергия. Модульные тесты — это инвестиция. Они часто занимают 3-5 строк кода на строку тестового покрытия. Это означает, что создание вашего функционального приложения может занять в 2–6 раз больше времени с незначительными улучшениями надежности. Ключевой компромисс, на который следует пойти, заключается в том, насколько быстро меняется код приложения. Для четких и неизменных требований модульные тесты являются хорошей инвестицией. Некоторые предприятия могут планировать код, который останется практически неизменным в течение нескольких лет. Я видел это в Google, и это хорошая стратегия для них. С другой стороны, для MVP модульные тесты могут быть проблемой. Полные страницы функциональности выбрасываются или возвращаются на чертежную доску. Библиотеки меняются, API и интерфейсы меняются, каждое требует серьезного рефакторинга в тестовом коде. Больше потраченного времени и больше возможностей для конкурента двигаться быстрее, чем вы. Во-вторых, часто бывает сложно настроить модульные тесты, которые дают осмысленное представление о функциональности кода. Не зная того, чего вы не знаете, вы можете просто подтвердить, что это работает так, как вы ожидаете. Это ничего не делает для обнаружения пограничных случаев или логических ошибок, которые проявятся в неожиданное время. Существуют и другие формы тестирования, которые дадут вам множество преимуществ надежной системы, особенно перед запуском для реальных пользователей. Приемочное тестирование является основным.
В целом, для MVP модульные тесты кажутся скорее пассивом, чем активом. Я рекомендую серьезное приемочное тестирование для функций, с которыми сталкивается пользователь, и не проводить модульное тестирование до бета-версии, где есть ценность в стабильности. Свяжитесь с нами, если у вас есть вопросы о том, как поддерживать здоровую культуру разработки во время создания MVP.
