В докладе рассмотрено зачем нужно покрывать код автотестами и почему многие этого до сих пор не делают. Что такое хорошие юнит-тесты и какую пользу они дают помимо собственно тестирования. Три принципа организации кода, упрощающие создание юнит-тестов: закон Деметры, внедрение зависимости и принцип единой ответственности. Каждый принцип разобран на примере, демонстрирующем его применение и получаемые при этом преимущества.

2. Принципы создания
тестируемого кода
Илья Шишков
старший разработчик компании Яндекс

3. Что такое автотесты?
▌ Юнит-тесты
▌ Интеграционные тесты
▌ Функциональные тесты
▌ Нагрузочные тесты
и другие виды тестов, которые выполняются регулярно и
автоматически
4

4. Зачем нужны автотесты

5. Без использования автотестов
▌ Новый код тестируется вручную
▌ Нет регулярного контроля
регрессии
▌ Многие баги проявляют себя
только в продакшене
▌ Любой релиз может стать
большим стрессом
6

6. При использовании автотестов
▌ Большинство багов выявляется
во время разработки
▌ Регрессия выявляется сразу
после заливки кода в
репозиторий
▌ Значительно возрастает
надёжность кода
▌ Работать гораздо комфортнее
7

7. Отдельно про юнит-
тесты

8. │Юнит-тест – тест одной
функции или класса
отдельно от остальных
частей системы

9. Преимущества юнит-тестов
▌ Контролируют корректность нового и существующего кода
▌ Сокращают время между допущением ошибки и её
обнаружением

10. Преимущества юнит-тестов
▌ Являются примером применения кода

11. Преимущества юнит-тестов
▌ Документируют поведение

12. Преимущества юнит-тестов
▌ Упрощают поиск ошибок

13. Не все юнит-тесты
одинаково полезны

14. Хороший юнит-тест
▌ Короткий, простой и понятный
▌ Проверяет что-то одно
▌ Обладает минимумом внешних зависимостей
▌ Тестирует контракт без предположений о его реализации
› Контракт – публичный интерфейс, задекларированное
поведение, гарантия безопасности исключений, предусловия,
постусловия и т.д.
15

15. Не все пишут автотесты

16. Я не пишу тесты, потому что
▌ Мне некогда, у меня полно
важных задач
▌ Я пишу код без багов
▌ Код слишком запутан
▌ Мне лень
17
▌ Закон Деметры
▌ Внедрение зависимости
▌ Принцип одной ответственности

17. Закон Деметры
Закон Деметры Внедрение зависимости Принцип одной
ответственности

18. Закон Деметры
▌ Don’t look for things. Ask directly
what you need!
19
Название взято из проекта 80-х гг
«Деметра», который использовал
идеи аспектно-ориентированного и
адаптивного программирования.
Проект был назван в честь
Деметры, греческой богини
земледелия.
Википедия

19. Закон Деметры
▌ Разработать класс для логирования сообщений
▌ Сообщения должны сохраняться в файл
▌ Сообщения должны накапливаться в буфере и сохраняться в
файл, только когда он заполнился
▌ Кроме того, запись в файл должна производиться после
логирования каждого K-го сообщения
20

20. Закон Деметры
21

21. Закон Деметры
22

22. Закон Деметры
23

23. Закон Деметры
24

24. Закон Деметры
25

25. Закон Деметры
▌ Хороший юнит-тест тестирует контракт без предположений о его
реализации
› Контракт – публичный интерфейс, задекларированное поведение,
гарантия безопасности исключений, предусловия, постусловия и т.д.
26

26. Закон Деметры
27

27. Закон Деметры
28
▌ Don’t look for things. Ask directly what you need!

28. Закон Деметры
29

29. Закон Деметры
30

30. Закон Деметры
Преимущества:
▌ Явное декларирование
зависимостей
▌ Отсутствие лишних
зависимостей
▌ Упрощение повторного
использования кода
▌ Упрощение тестирования
31
Недостатки:
▌ Увеличение числа параметров
▌ Вызовы становятся более
громоздкими

31. Внедрение зависимости
Закон Деметры Внедрение зависимости Принцип одной
ответственности

32. Внедрение зависимости
Внедрение зависимости (англ. Dependency injection, DI) —
процесс предоставления внешней зависимости программному
компоненту. Является специфичной формой «инверсии
управления» (англ. Inversion of control, IoC), когда она
применяется к управлению зависимостями.
Википедия
33

33. Внедрение зависимости
34

34. Внедрение зависимости
35

35. Внедрение зависимости
36

36. Внедрение зависимости
37

37. Внедрение зависимости
38

38. Внедрение зависимости
39

39. Внедрение зависимости
40

40. Внедрение зависимости
Преимущества
▌ Зависимость от интерфейса, а
не от реализации
▌ Гибкость
▌ Высокая комбинируемость кода
▌ Упрощение повторного
использования кода
▌ Упрощение тестирования
41
Недостатки
▌ Перенос деталей реализации в
интерфейс
▌ Код разбивается на два слоя:
отдельные блоки и слой их
«склейки»
▌ Становится сложнее понять, как
работает программа целиком

41. Принцип одной
ответственности
Закон Деметры Внедрение зависимости Принцип одной
ответственности

42. Robert C. Martin
│A class should have only
one reason to change
Принцип одной ответственности
43

43. Принцип одной ответственности
44

44. Принцип одной ответственности
45

45. Принцип одной ответственности
46

46. Принцип одной ответственности
47

47. Принцип одной ответственности
48

48. Принцип одной ответственности
49

49. Принцип одной ответственности
50

50. Принцип одной ответственности
51

51. Принцип одной ответственности
Преимущества
▌ Код разбивается на простые для
понимания блоки
▌ Высокая комбинируемость кода
▌ Упрощение повторного
использования кода
▌ Упрощение тестирования
52
Недостатки
▌ Появление большого
количества блоков
▌ Становится сложнее понять, как
работает программа целиком

52. Итоги
Преимущества применения
автотестов и описанных принципов
▌ Повышение стабильности кода
▌ Уменьшение числа
зависимостей
▌ Упрощение рефакторинга
▌ Ускорение разработки
▌ Спокойный сон после релиза 53

53. Ссылки
› Guide:WritingTestable Code (http://misko.hevery.com/code-
reviewers-guide/)
› The Clean CodeTalks
(http://www.youtube.com/playlist?list=PLBDAB2BA83BB6588E)
› AllYourTests areTerrible...
(https://www.youtube.com/watch?t=2285&v=u5senBJUkPc)
54

54. Контакты
vk.com/ishfb
ishfb@yandex-team.ru linkedin.com/in/ishfb
Илья Шишков
Старший разработчик компании Яндекс