1. Автотесты
Как перестать бояться и полюбить тестировать

2. Что будет?
 Зачем тестировать?
 Основные принципы
 Как тестировать?
 Что тестировать?
 Какие бывают тесты?
 Как не бросить их писать?

3. Зачем тестировать?

4. Регрессионная спираль смерти
Трудозатраты в зависимости от количества фич
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Начальный этап Больше фич Еще больше фич Коллапс
Ряд 3 Тестирование

5. Рефакторинг
Без автотестов С автотестами

6. You Ain’t Gonna Need It

7. Быстрый запуск нужного кода

8. Основные принципы
или
Каким должен быть правильный тест?

9. F.I.R.S.T.
 Fast
 Independent
 Repeatable
 Self-validating
 Timely

10. Автоматический запуск
My code sure works, why bother?

11. Читаемость

12. Достоверность
Ложные срабатывания подрывают доверие к тестам

13. Как тестировать?

14. Red-Green-Refactor
Обычно весь цикл занимает не более 15 минут

15. Arrange-Act-Assert

16. Адвокат дьявола

17. Outside-In & Bottom-Up

18. Mocks & Stubs
Stub Mock
 Не может провалить тест  Может провалить тест
 Проверяет, были ли вызваны SUT
 Реагирует заданным образом методы замоканного объекта
на внешние
 Используйте не более одного
воздействия, предоставляя мока для одного теста. Правда.
данные или некий контекст для
SUT

19. Что делать со старым кодом?
 Приоритезировать объекты, которые нужно покрыть тестами
 Написать интеграционные тесты для облегчения рефакторинга
 Провести рефакторинг для избавления от внешних зависимостей
 Написать юнит-тесты

20. Что тестировать?

21. Избегайте тестирования внутренней
структуры

22. Старайтесь тестировать фичи
 Именно покрытие автоматическими тестами фич, несущих ценность
для бизнеса, позволяет избежать разрастания регрессионной спирали
смерти
 Фичи медленнее изменяются со временем. Если требования к фиче
все-таки изменились, хорошо начать с того, чтобы модифицировать
тесты под новые требования, а уже потом – код, под новые
(падающие!) тесты
 Тесты на фичу, написанные до еѐ реализации, позволяют успешно
реализовать YAGNI-принцип и могут служить одним из критериев
приемки

23. Какие бывают тесты?

24. Юнит тесты
 Быстрые
 System Under Test == Class Under Test
 Изменение тестируемого класса с большой вероятностью приведет к
поломке тестов.

25. Приемочные тесты
• Не используют (в идеале) фейки
• Тестируют конкретные бизнес-фичи
• Более устойчивы – изменения
обычно не приводят к поломке тестов

26. UI тесты
 Фреймворки: Coded UI test project, Selenium
 Медленные
 Требуют специального окружения, где будет разворачиваться
приложение

27. Как не бросить писать тесты?

28. Аргументы против тестов
 У нас нет времени, нужно писать код!
 Тесты только мешают – постоянно приходится переписывать!

29. Как же не бросить их писать?
 Принять наличие тестов, как одно из условий DoD
 Проводить Code Review тестов
 Делиться опытом внутри команды и между командами

30. Резюме
 Автоматические тесты ускоряют процесс разработки
 Чтобы тесты выполняли свои функции, они должны быть написаны
вовремя, запускаться автоматически, быть читаемыми и надежными
 Невыполнение хотя бы одного из условий скорее всего приведет к
скопищу бесполезных тестов, которые проще отключить, чем
разбираться как они работают
 Делитесь опытом – вместе мы сильнее

31. Рекомендации
• The Art of Unit Testing – Roy Osherove
• Pluralsight – TDD course,
• Pluralsight – Outside-in TDD

32. Спасибо за внимание!