Про тестирование в стартапе
Я давно парился над вопросом тестов. С одной стороны, тесты — это клево и все такое (Ruby-сообщество тесты ценит). С другой стороны, возьмем ситуацию стартапа:
- Количество ресурсов ограничено. За одно и то же время можно либо реализовать 1 элемент функционала и тесты к нему, либо 2 элемента функционала без тестов.
- Много кода пойдет на выброс, поскольку будущее слабо определено.
Получается, что в стартапе большого смысла увлекаться тестами нет. Наиболее ограниченный ресурс — время, и тратить его на тестирование кода с очень малым временем жизни бессмысленно. Лучше сделать 2 фичи и потом выбросить одну, чем сделать одну, но с тестами.
Вчера я слушал подкаст Эрика Риса про lean startups, там мне понравилась метафора про тесты как иммунную систему проекта, которая предотвращает поломки.
В итоге я пока остановился на следующем:
- Юнит-тесты для критически важной бизнес-логики, которые проверяют корректность ее работы, в т.ч. во всяких изощренных условиях.
- Простые тесты контроллеров. В нашем проекте поломки в основном происходят из-за того, что какой-нибудь хелпер переименовался или изменился путь к странице, а старое blah_blah_path где-то осталось. Поэтому достаточно простых get, post и put с проверкой кода возврата. Грубо говоря, если страница срендерилась или редирект произошел, то поломки нет — простейшая иммунная система.
Пробовал несколько раз Cucumber, неудачно. На Ruby писать быстрее и больше возможностей.
Кроме того, важность тестов, видимо, растет с ростом количества участников проекта. Возясь с чужим кодом, я предпочту иметь тесты.
