Илья Шишков, Принципы создания тестируемого кода

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

Логотип партнера

3

Что такое автотесты?

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

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

5

Без использования автотестов

▌ Новый код тестируется вручную

▌ Нет регулярного контроля регрессии

▌ Многие баги проявляют себя только в продакшене

▌ Любой релиз может стать большим стрессом

6

При использовании автотестов

▌ Большинство багов выявляется во время разработки

▌ Регрессия выявляется сразу после заливки кода в репозиторий

▌ Значительно возрастает надёжность кода

▌ Работать гораздо комфортнее

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

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

Преимущества юнит-тестов

▌Контролируют корректность нового и существующего кода

▌Сокращают время между допущением ошибки и её обнаружением

Преимущества юнит-тестов

▌ Являются примером применения кода

Преимущества юнит-тестов

▌ Документируют поведение

Преимущества юнит-тестов

▌ Упрощают поиск ошибок

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

14

Хороший юнит-тест▌Короткий, простой и понятный

▌Проверяет что-то одно

▌Обладает минимумом внешних зависимостей

▌Тестирует контракт без предположений о его реализации

› Контракт – публичный интерфейс, задекларированное поведение, гарантия безопасности исключений, предусловия, постусловия и т.д.

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

16

Я не пишу тесты, потому что

▌ Мне некогда, у меня полно важных задач

▌ Я пишу код без багов

▌ Код слишком запутан

▌ Мне лень

▌ Закон Деметры

▌ Внедрение зависимости

▌ Принцип одной ответственности

Закон Деметры

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

18

Закон Деметры

▌ Don’t look for things. Ask directly what you need!

Название взято из проекта 80-х гг «Деметра», который использовал идеи аспектно-ориентированного и адаптивного программирования.

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

Википедия

19

Закон Деметры

▌Разработать класс для логирования сообщений

▌Сообщения должны сохраняться в файл

▌Сообщения должны накапливаться в буфере и сохраняться в файл, только когда он заполнился

▌Кроме того, запись в файл должна производиться после логирования каждого K-го сообщения

20

Закон Деметры

21

Закон Деметры

22

Закон Деметры

23

Закон Деметры

24

Закон Деметры

25

Закон Деметры▌ Хороший юнит-тест тестирует контракт без предположений о

его реализации› Контракт – публичный интерфейс, задекларированное

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

26

Закон Деметры

27

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

28

Закон Деметры

29

Закон Деметры

30

Закон ДеметрыПреимущества:▌ Явное декларирование

зависимостей▌ Отсутствие лишних

зависимостей

▌ Упрощение повторного использования кода

▌ Упрощение тестирования

Недостатки:▌ Увеличение числа

параметров

▌ Вызовы становятся более громоздкими

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

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

32

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

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

Википедия

33

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

34

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

35

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

36

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

37

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

38

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

39

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

40

Внедрение зависимостиПреимущества▌ Зависимость от интерфейса,

а не от реализации▌ Гибкость

▌ Высокая комбинируемость кода

▌ Упрощение повторного использования кода

▌ Упрощение тестирования

Недостатки▌ Перенос деталей

реализации в интерфейс▌ Код разбивается на два

слоя: отдельные блоки и слой их «склейки»

▌ Становится сложнее понять, как работает программа целиком

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

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

Robert C. Martin

│A class should have only one reason to change

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

42

43

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

44

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

45

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

46

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

47

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

48

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

49

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

50

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

51

Принцип одной ответственностиПреимущества▌ Код разбивается на простые

для понимания блоки

▌ Высокая комбинируемость кода

▌ Упрощение повторного использования кода

▌ Упрощение тестирования

Недостатки▌ Появление большого

количества блоков▌ Становится сложнее

понять, как работает программа целиком

52

ИтогиПреимущества применения автотестов и описанных принципов▌ Повышение стабильности

кода

▌ Уменьшение числа зависимостей

▌ Упрощение рефакторинга

▌ Ускорение разработки

▌ Спокойный сон после релиза

53

Ссылки› Guide: Writing Testable Code (

http://misko.hevery.com/code-reviewers-guide/)› The Clean Code Talks (

http://www.youtube.com/playlist?list=PLBDAB2BA83BB6588E)

› All Your Tests are Terrible... (https://www.youtube.com/watch?t=2285&v=u5senBJUkPc)

Контакты

vk.com/ishfb

ishfb@yandex-team.ru

linkedin.com/in/ishfb

Илья Шишков

Старший разработчик компании Яндекс