Тесты и тестирование
Возможно, в сайте из 3 контроллеров и 15 страниц, тесты и не нужны. Я обычно не делаю тесты на маленьких проектах, которые пишу один.
В случае, если проект собирается быть большим, длиться долго, а команда состоит больше чем из одного человека, то тесты — крайне желательный инструмент для того, чтобы разработка не вышла из под контроля. Без тестов в какой-то момент невозможно внести серьезное изменение в код, потому что знаешь, что такое изменение заденет еще некоторые части и точно знаешь, что все зависимости точно не учтешь. В этот момент разработка превращается в постоянное исправление ошибок, при которых снова вносятся ошибки и так до бесконечности.
Вот что пришло мне сегодня на почту от cruisecontrol
Finished in 434.861501 seconds
2486 examples, 35 failures, 3 pending </pre>
Сразу бросаются в глаза 2 проблемы:
- тесты выполняются с ошибками;
- тесты выполняются очень долго.
Если тесты валятся и никто их не чинит, то к этому быстро привыкают и перестают обращать на это внимание. Избежать это можно следующим образом — не делать новых комитов, пока тесты не починит тот, кто их сломал.
К моему приходу в linkfeed были еще тесты, которые то проходили, то не проходили. Чтобы избежать этого, каждый раз
создавалась заново тестовая база, на ней прогонялись все миграции и фикстуры. Но и такой подход не всегда помогал. В
конце-концов, все такие тесты были исправлены (обычно всегда это были тесты с вызовом Model.first без :order, который не всегда
достает из БД одни и те же данные).
Несколько ускорить выполнение тестов можно, если запускать spec_server, а потом spec с ключом -X. Как задействовать 2 ядра моего процессора для тестов я так пока и не придумал.
Если вы прогоняете конкретный spec-файл, значительно ускорить разработку позволит ключ -e, позволяющий выполнить
конкретную проверку, а не весь файл (я настоятельно рекомендую потратить 5 минут на изучение spec --help).
Возможно, имеет смысл разделить все тесты на «быстрые» и «медленные». Быстрые прогонять перед комитом на локальной машине, а «медленные» пусть выполняет только cruisecontrol и шлет письма в случае возникновения ошибок.
Еще одна практика, которую стоит взять за правило — перед тем, как поправить ошибку, написать на нее тест, которые провалится. В идеале, конечно, стоит писать тесты перед кодом, но эту практику мы у себя пока не внедрили.