Технические заметки одного Евтуховича

Рассказ о серых трудовых буднях инженера программных систем

Тесты и тестирование

| Комментарии

Возможно, в сайте из 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 и шлет письма в случае возникновения ошибок.

Еще одна практика, которую стоит взять за правило — перед тем, как поправить ошибку, написать на нее тест, которые провалится. В идеале, конечно, стоит писать тесты перед кодом, но эту практику мы у себя пока не внедрили.

Комментарии