Как мы используем автоматическое тестирование

Как мы используем автоматическое тестирование

Аватар пользователя Евгений, Ведущий разработчик
Евгений, Ведущий разработчик
01 декабря 2014

Ни для кого не секрет, что проект с тестами гораздо лучше проекта без тестов.

В него не так страшно вносить изменения да и постоянная уверенность что все работает так, как задумали позволяет чувствовать себя лучше

В нашей компании мы используем следующие виды автоматических тестов:

  • Acceptance tests - приемочные тесты, написанные с учетом требований заказчика
  • Integration tests - интеграционные тесты. С помощью них мы тестируем поведение системы в комплексе с учетом БД и других зависимостей.
  • Unit tests - модульные тесты. Предназначены для тестирования поведения отдельных классов, все зависимости на другие классы заменяются Mock или Stub объектами

Как мы понимаем, что нужно писать тесты

  • Если проект планируется больше чем на 3-4 месяца. За такой срок команда успевает забыть требования к функционалу, который делался в начале проекта, и тесты помогают не потерять эти требования
  • Если есть нетривиальная логика класса/метода, требования к которой сложно уложить в голове - пишем юнит тест
  • Если видим требования, которые потенциально могут измениться - пишем интеграционный или приемочный тест
  • Если находим баг - пишем тест, что бы он больше не повторился

При выборе того, какой тест писать учитываем то, что самые дешевые и простые в поддержке модульные тесты, но в то же время у них наиболее слабая связь с требованиями заказчика.

Как мы выбираем, какие тесты писать

  • Приемочные тесты пишут наши QA специалисты (или программисты, если необходима их помощь)
  • Интеграционные тесты пишем в случаях:
    • если хотим проверить работу системы в комплексе
    • если затраты на создание и поддержку контекста их выполнения (например состояния БД) меньше, чем затраты на создание Mock или Stub для модульных тестов
  • Модульные случаи во всех остальных случаях

Что происходит с тестами потом

Во первых - у нас есть система Continius Integration, с помощью которой мы отслеживаем, что все тесты работают после каждого коммита. Во вторых - у нас есть процесс Code Review, в рамках которого проверяются, в том числе, тесты по следующим требованиям:

Требования к тестам

  • Должны соблюдаться правила именования тестов:
    • Для модульных тестов тестовый класс должен называться относительно класса, который должен быть протестирован с добавлением окончания Test
    • Для интеграционных тестов название тестового класса выбирается исходя из названия тестируемой части системы
    • Название теста должно отражать его содержание
  • Тест должен иметь комментарий, в котором описано что именно тестируется, входные условия и ожидаемый результат
  • Тест должен быть построен по ААА шаблону - т.е. должен содержать 3 зоны Arrange-Act-Assert. В зоне Arrange настраивается контекст, в зоне Act выполняется тестируемое действие, в зоне Assert производятся проверки
  • Тест должен быть лаконичным. Прячем всю лишнюю обработку в хелперы.
  • Тест не должен проверять все возможные ситуации (и тем более позитивные и негативные тесты). Допускается вложение 2-3 ситуаций совпадающих по контексту, который должен следовать из названия теста. Если тест ломается, должно быть однозначно понятно что именно пошло не так.
  • В тестах стараемся не использовать ни условия, ни циклы.
  • Тесты не должны иметь влияние друг на друга и не зависеть от окружения (если необходим какой-либо контекст, тест сам заботиться о его создании и корректном удалении).
  • По возможности тесты пишем максимально быстрыми.

В итоге все разработчики понимают как и когда писать тесты и мы можем быть уверены в качестве нашего кода.

Наверняка можно что-нибудь улучшить в этом процессе, и я был бы очень благодарен читателям за обратную связь.