Ситуация: вам достался пятилетний проект, который писали три команды, и ни с кем из них не связаться. Проект запутанный и непонятный: тут jQuery, а тут Backbone, тут интеракторы, а тут контроллеры на 500 строк. Тестов — ноль.
Начните с интеграционных тестов
В ситуации выше сложно писать модульные, изолированные тесты: вы не знаете, что код должен был делать и что он делает сейчас.
Кроме того, часто модули плохо структурированы и сильно связаны с другими модулями. Из‑за этого писать модульные тесты — мука: они на 90% состоят из настройки окружения и зависимостей, а на 10% из проверок.
Чтобы получить максимум пользы от тестов при минимуме затрат, используйте интеграционные тесты, проверяющие не отдельные модули, а приложение целиком так, как это делал бы человек.
Определите, какие функции и сценарии критичны для клиента, и зафиксируйте требуемое поведение в интеграционных тестах.
В книгах бюро важно, чтобы каждый разворот выглядел так, как его утвердил арт‑директор. Оторвавшаяся подпись, незагрузившаяся картинка или отсутствие сглаживания в абзаце — баг, с которым нельзя выпускать книгу.
Когда делали «Типографику и вёрстку», внешний вид разворотов тестировали вручную. Это было утомительно, долго и не гарантировало отсутствие проблем.
Чтобы автоматизировать эти проверки, собрали инструмент интеграционного визуального тестирования, Педанта: он делает скриншоты книги в ключевых точках и сравнивает с эталонами.
Педант защитил нас от 95% проблем с отображением разворотов и открыл дорогу к безболезненному рефакторингу книг и книжного движка. Мы провели уже 14 фундаментальных изменений движка: от автоматической типографики и перехода на
Если у вас веб‑приложение, для интеграционного тестирования в браузере используйте Capybara, Nightwatch.js или CasperJS. Если API‑only, взгляните на RSpec API Documentation или Chai‑HTTP. Если важней всего, как страница выглядит, попробуйте PhantomCSS или Gemini.
Постепенно добавьте модульных тестов
Как правило, одних интеграционных тестов мало: они медленные и редко проверяют краевые случаи. Чтобы разработчики быстро понимали, что и где сломали их изменения, нужны быстрые, изолированные модульные тесты.
Самый простой способ добавить их в легаси‑проект — не принимать пулреквесты без тестов. Решили отрефакторить модуль — сначала покрыли его тестами, нашли баг в модуле авторизации — сначала добавили тест. Так со временем у проблемных старых модулей появится тестовое покрытие.
Чтобы эта стратегия сработала, нужно сделать так, чтобы работать с тестами было проще, чем с кодом. Это — тема для отдельного совета.
Ещё по теме:
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.