Почти любое мобильное или веб-приложение получает данные с бэкенда через REST. При тестирование такого приложение часто возникает вопрос, кому отправить дефект на устранение? Чья реализация клиента или сервера является ошибочной? Для ответа на этот вопрос: мы рассмотрим такие виды спецификации как RAML и Swagger; увидим как их использование упрощает ручного тестирования в Postman; познакомимся с такими инструментами для автоматизации тестирования как Dredd и Abao; разберем как поставить процесс контрактного тестирования Доклад ориентирован в первую очередь на автоматизацию процессов тестирования, тем не менее его элементы будут полезны и при ручном тестирование.

1. Контрактное
тестирование на
примерах
или Contract First
23 сентября, 2017

2. Никита Галкин
Верю, что:
▰ Любая проблема должна решаться
на нужно уровне
▰ Сложности не в технологиях,
сложности в людях
▰ Проблемы надо обсуждать,
идеи – продавать,
а решения – демонстрировать
2

3. 3
Что такое проверка
качества?

4. 4
Проверка
соответствия
требованиям

5. Что такое качество?
5
Атрибуты:
▰ переносимость;
▰ функциональность;
▰ эффективность;
▰ удобство использования
(юзабилити);
▰ тестируемость;
▰ понятность;
▰ модифицируемость.

6. Об ожиданиях
6

7. 7
Проверка
соответствия
требованиям
ОЖИДАНИЯМ

8. Основные идеи
8
▰ Задача QA Engineer проверять ожидания
▰ Людям необходимо помогать договариваться
▰ Требования это синхронизированные ожидания
▰ Бизнес платит за реализацию своих ожиданий,
за реализованную функциональность

9. 9
Виды тестов

10. Виды тестов
10
▰ Linting – между разработчиками, что код понятен
▰ Unit – между разработчиками, что код не сломают
▰ Functional e2e – между бизнесом и разработчиками,
что ПО работает как ожидается
▰ Performance – между бизнесом и разработчиками,
что ПО обеспечение эффективно

11. 11
Personal story

12. Типичная ситуация
12
Мобильное приложение
Новая фича не работает
А может даже регрессия перестала работать
Вопрос на кого отправлять баг? Mobile/Backend/Content?

13. Slack bot
13
Венгры

14. 14
Contract first

15. Что есть контракт
15
▰ Между разработчиками из разных команд
▰ Человеко и машино читаемый
▰ Используется для тестирования и разработки,
иначе устареет
▰ Является единственным источником правды о
договорености
▰ Контракт это не документация, а скорее спецификация

16. 16
Контракт
для REST API

17. О чем надо договориться для использования REST
17
▰ Endpoints – где лежат сущности
▰ Methods – действия с сущностями
▰ Headers – метаданные
▰ Status Codes – варианты ответов
▰ Body shemas – форматы ответов и запросов

18. Текущие форматы
18
▰ raml
▰ swagger
▰ WADL
▰ API BluePrint
▰ И прочие

19. 19
Контракт надо
читать и писать,
поэтому YAML!

20. Endpoints and methods
20
/pet:
post:
put:
/pet/{petId}:
get:
post:
delete:

21. Responses
21
/pet:
post:
responses:
201:
description: Created
405:
description: Invalid input

22. 22
Что вам даст
наличие контракта

23. Использование контракта для тестирования
23
▰ Одинаковые ожидания у всех членов команды
▰ Автогенерируемая документация
▰ Возможность загрузить сразу в Postman
▰ Создание mock для вашего REST API
▰ Автовалидация входных данных
▰ Упрощения тестирование для Backend
▰ И прочее...

24. 24
Использование
контракта для
тестирования

25. Использование контракта для тестирования
25
▰ Тест кейс – endpoint + method + response
▰ Что проверяем:
▻ Код ответа
▻ Заголовки
▻ Формат body

26. Использование контракта для тестирования
26
▰ Arrange – Подготовить данные для запроса
▰ Act – Выполнить запрос
▰ Assert – Проверить соответствие
▻ Код ответа
▻ Заголовки
▻ Формат body
▰ PostAct – Убрать за собой

27. 27
Изменение
контракта не повод
переписывать тесты!

28. Использование контракта для тестирования
28
▰ Arrange – Подготовить данные для запроса
▰ Act – Выполнить запрос
▰ Assert – Проверить соответствие
▻ Код ответа
▻ Заголовки
▻ Формат body
▰ PostAct – Убрать за собой

29. 29
Хватить
дублировать!
Используем парсинг
и хуки

30. Использование контракта для тестирования
30
▰ Arrange – Подготовить данные для запроса
▰ Act – Выполнить запрос
▰ Assert – Проверить соответствие
▻ Код ответа
▻ Заголовки
▻ Формат body
▰ PostAct – Убрать за собой

31. Использование контракта для тестирования
31
▰ Arrange – Подготовить данные для запроса – Before
▰ Act – Выполнить запрос – на основании контракта
▰ Assert – Проверить соответствие – на основании контракта
▰ PostAct – Убрать за собой – After

32. 32
Dredd для Swagger

33. Dredd
33
▰ Поддерживаемые спецификации:
▻ Swagger
▻ Api BluePrint
▻ Что вы допилите в этот OpenSource проект
▰ Хуки на GO, PHP, Python, JavaScript
▰ Написан на Node.js

34. 34
Abao для RAML 0.8

35. Abao
35
▰ Поддерживаемые спецификации:
▻ Raml 0.8
▰ Хуки на JavaScript и CoffeeScript
▰ Написан на CoffeeScript

36. 36
СПАСИБО!
УПРАВЛЯЙТЕ ОЖИДАНИЯМИ,
ДОГОВАРИВАЙТЕСЬ И
АВТОМАТИЗИРУЙТЕ!
Вы можете найти меня на твиттере @galk_in
Слайды доступны speakerdeck.com/galkin
Или на моем сайте galk.in