● Что такое Outside-In? ● Что такое Inside-Out? ● Какие +и -в Outside-In подходе ● Какие +и -в Inside-Out подходе ● F.I.R.S.T (бонус)

1. “Outside In” подход к
тестированию веб-
приложения 🤘
Александр Вишняков
Full Stack Web Engineer
https://blog.maddevs.io
https://maddevs.io

2. Коротко о докладе
● Что такое Outside-In?
● Что такое Inside-Out?
● Какие + и - в Outside-In подходе
● Какие + и - в Inside-Out подходе
● F.I.R.S.T (бонус)

3. Что такое Outside-In?
✓ #London School
✓ #Top-Down
✓ #Mockist TDD
✓ #YAGNI

4. Outside-In и группы заинтересованных
✓ Principals - Люди, которые покупают ваше программное
обеспечение - самый важный участник.
✓ End Users (Конечные пользователи) - Люди, которые
взаимодействуют с вашим продуктом. Они испытывают ваше
программное обеспечение в реальном мире.
✓ Partners (Партнеры) - Люди, которые заставляют ваш продукт
работать в реальной жизни, такие как рабочие группы, а
также деловые партнеры и системные интеграторы.
✓ Insiders (Инсайдеры) - Люди в вашей компании, которые
имеют некоторое влияние на то, как ваша команда
разрабатывает программное обеспечение.

5. Mockist TDD (Mock Objects)
Термин «фиктивные объекты» (Mock Objects) стал популярным
для описания объектов особого случая, которые имитируют
реальные объекты для тестирования. Большинство языковых сред
теперь имеют каркасы, которые позволяют легко создавать
фиктивные объекты. Однако часто не осознают, что фиктивные
объекты - это всего лишь одна из форм объекта тестирования в
особом случае, которая позволяет использовать другой стиль
тестирования. Они поощряют тестирование, основанное на
проверке поведения.
© Мартин Фаулер

6. YAGNI - означает “Вам это не понадобится”

7. Архитектурная пирамида и Batman YAGNI

8. Поиск решений

9. ✓ Определяемся с внешним видом нашей системы
✓ Выделяем ее каркас (очертания)
Outside-In

10. ✓ Определяемся с зависимостями
Outside-In

11. Outside-In
✓ Реализуем самый минимум - это каркас
✓ Пишем Приемочные Тесты
✓ Все что не готово - мокается (все что заштриховано)

12. Outside-In
✓ Реализуем часть накрывающую багажник
○ (соблюдая требования потребителя)
✓ Пишем Приемочные тесты

13. Outside-In
✓ Добавляем основу на которую крепится каркас
✓ Пишем Приемочные Тесты

14. Outside-In
✓ Добавляем оси с колесами
✓ Знаем что нам нужно 4 колеса (2 слева и 2 справа) и опять
пишем Приемочные Тесты

15. Outside-In
✓ Добавляем 4 двери (2 слева и 2 справа)
✓ И пишем Приемочные Тесты

16. Outside-In
✓ Добавляем 8 стекл (лобовое, заднее, 3 лева и 3 справа)
✓ И пишем Приемочные Тесты

17. Outside-In
✓ Ну и так далее, с постепенной заменой замоканных
зависимостей на реальные реализации
✓ И пишем Приемочные Тесты для каждой новой реализации.
✓ И в итоге готовая система, которая соответствует
потребительским требованиям

18. Почему Приемочные тесты?
✓ Что вы делаете руками когда добавляете интерфейсные части?
○ Кликаете, скролите, вводите данные, скачиваете, загружаете
✓ Используя GHERKIN вы описываете тесты понятные Стек-
Холдерам
✓ В Web, разработке прежде всего вы взаимодействуете с
браузером!
✓ Так автоматизируйте рутинные ручные тесты!
✓ Это ваш QA на стероидах

19. Почему не Юнит и не Функциональные?
✓ Так как большая часть кода будет замокана
✓ Не ясны до конца требования по глубине функционала
✓ Все уточняется по мере движения в глубь
✓ Частые рефакторинги и изменение кода (замучаетесь менять все
три вида тестов). Увеличение времени внесения изменений.

20. + и - Outside-In
Плюсы:
＋ Быстрый и понятный для клиента результат (так как начинаете с UI)
＋ Детектирование подходящей структуры данных для получения из API
＋ Меньше переделок бекендерам
＋ Быстрее вносятся изменения
＋ Изменяются только приемочные тесты (QA-на стероидах)
Минусы:
﹣ Недостаточный опыт команды = появление 💩-Кода
﹣ Отсутствие первое время юнит и функциональных тестов

21. Плюсы:
＋ Фронтенд диктует требования для бекенда
＋ Меньше проблем для фронтендера
Минусы:
﹣ Бекенд может значительно отставать от фронтенда
﹣ Больше нагрузки на фронтенд
﹣ Злой бекендер
+ и - Outside-In

22. Что такое Inside-Out?
✓ #Classic School
✓ #Bottom-Up
✓ #Classic TDD

23. + и - Inside-Out
Плюсы:
﹢ Следование практикам TDD
﹢ Наличие Юнит и Функциональных тестов
﹢ Применим в условиях, когда нет очертания системы
﹢ Работает когда не понятно взаимодействие компонента с системой
Минусы:
﹣ Проблема с согласованием UI и бекенда
﹣ Нет полной картины системы
﹣ Чревато твиками, переделками и так далее

24. Inside-Out (плохой случай)

25. Inside-Out (плохой случай)
На фронтенде ожидаешь ……………………. а бекендер тебе выдает

26. Инструменты тестирования node.js проекта
● Cucumber.js
● Puppeteer
○ Chrome
○ Firefox
○ Microsoft Edge

27. Puppeteer + Chrome

28. Puppeteer + Microsoft Edge

29. Puppeteer + Firefox github.com/puppeteer/juggler

30. F.I.R.S.T (Алфавит успешных тестов)
F- (Fast as Possible)
Тест должен проходить настолько быстро,
насколько это возможно

31. F.I.R.S.T (Алфавит успешных тестов)
I- (Independent)
Тест никаким образом не должен зависеть от:
● Порядка запуска тестов/сценариев
● От других тестов, что подготавливают “почву”

32. F.I.R.S.T (Алфавит успешных тестов)
R- (Repeatable)
Тест можно запускать столько раз, сколько нужно,
не переживая за:
● кол-ва запусков
● исчерпанные ресурсы
● наличие каких либо данных
● от ручного запуска каких либо моковых и не очень сервисов

33. F.I.R.S.T (Алфавит успешных тестов)
S- (Self-validating)
Тест должен быть зеленым по срабатыванию одного условия проверки
Условие не должно:
● Выдавать false-позитивы при изменении кода или компонентов на
странице
● Однозначно гарантировать корректность условия. Если все ОК - то
действительно все ОК.
● Быть постоянным при запуске несколько раз

34. F.I.R.S.T (Алфавит успешных тестов)
T- (Timely)
Тесты нужно писать вовремя
● Тест/Сценарий написанный позже, чем надо, будет давать
результаты тоже позже.
● Без одного из видов тестов, вы однозначно допустите ошибку.
○ Как бы вы не проверяли и какие бы вы ни были бы внимательными.

35. Шпасибо! 🙏
github.com/CyberLight
https://medium.com/@cyberlight
maddevs.io
blog.maddevs.io
Александр Вишняков
Full Stack Web Engineer
C