АвтотестыКак перестать бояться и полюбить тестировать
Что будет?
Зачем тестировать?
Основные принципы
Как тестировать?
Что тестировать?
Какие бывают тесты?
Как не бросить их писать?
Зачем тестировать?
Регрессионная спираль смерти
Начальный этап Больше фич Еще больше фич Коллапс0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Трудозатраты в зависимости от количества фич
Разработка Тестирование
Андрей Зубов
Чем больше фич реализовано в продукте, тем большее времени требуется, чтобы убедиться,что старый функционал работает корректно. При ручном тестировании с развитием продукта регрессионное тестирование занимает все больше времени, пока, наконец, затраты на тестирование не начинают превышать затраты на разработку.
Рефакторинг
Без автотестов С автотестами
Андрей Зубов
Код нуждается в постоянном улучшении. Архитектурные решения, бывшие удачными и оправданными вчера, сегодня уже не подходят. Рефакторинг без автотестов похож на попытку переставить хрусталь с полки на полку в темном чулане.
You Ain’t Gonna Need It
Андрей Зубов
Тесты, написанные еще до написания кода приложения, позволяют лучше понимать, что действительно нужно реализовать прямо сейчас, а что может подождать какое-то время или вообще не понадобится.
Быстрый запуск нужного кода
Андрей Зубов
Даже если нет автотестов, мы всё равно тестируем свой код, запуская приложение и проходя по шагам реализуемый функционал. Но часто в крупных проектах запустить всё приложение целиком не проще, чем подготовить к запуску спейсшаттл. В процессе отладки это может потребоваться сделать несколько раз. Даже если приложение и запускается быстро, продраться сквозь череду экранов пользовательского интерфейса может занять какое-то время. Автоматические тесты сразу запускают именно тот код, который вас интересует в данный момент.
Основные принципыили
Каким должен быть правильный тест?
F.I.R.S.T.
Fast
Independent
Repeatable
Self-validating
Timely
Андрей Зубов
Тесты должны выполняться быстро (от долей секунды, до нескольких минут. Чем дольше выполняются тесты, тем реже их получается запускать. Тесты не должны зависеть друг от друга. Тесты должны давать одинаковые результаты на каждый прогон, если в кодовой базе не было изменений. Тесты сами должны проверять, правильно ли выполняется тот или иной код. Тесты должны быть написаны вовремя - поздно обычно означает никогда.
Автоматический запуск
My code sure works, why bother?
Андрей Зубов
Тесты должны регулярно автоматически прогоняться. Люди часто забывают, или ленятся их запускать, отчего эффективность автотестов резко падает
Читаемость
Андрей Зубов
Мы пишем тесты не для билд-сервера, но для людей, которые будут поддерживать наш код (возможно, это мы сами через несколько месяцев)
Достоверность
Ложные срабатывания подрывают доверие к тестам
Андрей Зубов
Если тест слишком часто кричит "Волк!", то в какой-то момент ему перестанут верить и обращать на него внимание, даже если "волк" действительно случится.
Как тестировать?
Red-Green-Refactor
Обычно весь цикл занимает не более 15 минут
Андрей Зубов
Шаг с проверкой, что тест падает, является очень важным. Часто может оказаться, что тест проверят совсем не те условия, которые нужны для проверки разрабатываемого функционала и внесение в код ломающих изменений не повлечет за собой падения теста.
Arrange-Act-Assert
Андрей Зубов
читаемость внутри теста также должна быть на высоком уровне, чтобы разработчик смог быстро сориентироваться, что происходит во время его выполнения
Адвокат дьявола
Андрей Зубов
Удостовериться, что ваша группа тестов тестирует именно то, что нужно, можно стараясь написать код так, чтобы он заставлял пройти тест самым простым способом. Если при этом система очевидно не выполняет своих функций, значит требуются уточняющие тесты. В конце концов набор тестов станет надежным и сразу укажет, что тестируемая система стала вести себя неожиданным образом при внесении изменений в кодовую базу
Outside-In & Bottom-Up
Андрей Зубов
Два подхода к разработке: Сначала писать крупные компоненты и заменять внутренние фальшивыми объектами, или сначала писать внутренние компоненты, объединяя их уже готовые в более крупную систему.
Mocks & StubsStub
Не может провалить тест
Реагирует заданным образом на внешние воздействия, предоставляя данные или некий контекст для SUT
Mock Может провалить тест
Проверяет, были ли вызваны SUT методы замоканного объекта
Используйте не более одного мока для одного теста. Правда.
Андрей Зубов
Фальшивые объекты в коде хорошо именовать согласно их назначению
Что делать со старым кодом?
Приоритезировать объекты, которые нужно покрыть тестами
Написать интеграционные тесты для облегчения рефакторинга
Провести рефакторинг для избавления от внешних зависимостей
Написать юнит-тесты
Что тестировать?
Избегайте тестирования внутренней структуры
Старайтесь тестировать фичи
Именно покрытие автоматическими тестами фич, несущих ценность для бизнеса, позволяет избежать разрастания регрессионной спирали смерти
Фичи медленнее изменяются со временем. Если требования к фиче все-таки изменились, хорошо начать с того, чтобы модифицировать тесты под новые требования, а уже потом – код, под новые (падающие!) тесты
Тесты на фичу, написанные до её реализации, позволяют успешно реализовать YAGNI-принцип и могут служить одним из критериев приемки
Какие бывают тесты?
Юнит тесты
Быстрые
System Under Test == Class Under Test
Изменение тестируемого класса с большой вероятностью приведет к поломке тестов.
Приемочные тесты
• Не используют (в идеале) фейки• Тестируют конкретные бизнес-фичи• Более устойчивы – измененияобычно не приводят к поломке тестов
UI тесты
Фреймворки: Coded UI test project, Selenium
Медленные
Требуют специального окружения, где будет разворачиваться приложение
Как не бросить писать тесты?
Аргументы против тестов
У нас нет времени, нужно писать код!
Тесты только мешают – постоянно приходится переписывать!
Андрей Зубов
На самом деле, если требуется поставить качественный продукт в сжатые сроки, наличие тестов только поможет, так как позволяют быстрее выполнять код, который пишет разработчик. Если требуется изменить поведение тестируемой системы, то в первую очередь должны поменяться тесты, чтобы отразить это новое состояние
Как же не бросить их писать?
Принять наличие тестов, как одно из условий DoD
Проводить Code Review тестов
Делиться опытом внутри команды и между командами
Андрей Зубов
и главное - показать, что тесты приносят пользу. Положительный опыт очень важен.
Резюме
Автоматические тесты ускоряют процесс разработки
Чтобы тесты выполняли свои функции, они должны быть написаны вовремя, запускаться автоматически, быть читаемыми и надежными
Невыполнение хотя бы одного из условий скорее всего приведет к скопищу бесполезных тестов, которые проще отключить, чем разбираться как они работают
Делитесь опытом – вместе мы сильнее
Рекомендации
• The Art of Unit Testing – Roy Osherove• Pluralsight – TDD course,• Pluralsight – Outside-in TDD