5.1 Домашнее задание к занятию «2.3. Patterns»

В качестве результата пришлите ссылку на ваш GitHub-проект в личном кабинете студента на сайте netology.ru.

Все задачи этого занятия нужно делать в разных репозиториях.

Шаблон для ДЗ.

Важно: проекты с решением задач по данной теме реализуются с использованием Selenide.

Важно: если у вас что-то не получилось, то оформляйте issue по установленным правилам.

Важно: не делайте ДЗ всех занятий в одном репозитории. Иначе вам потом придётся достаточно сложно подключать системы Continuous integration.

Как сдавать задачи

1. Инициализируйте на своём компьютере пустой Git-репозиторий.
2. Добавьте в него готовый файл .gitignore.
3. Добавьте в этот же каталог код ваших автотестов.
4. Сделайте необходимые коммиты.
5. Добавьте в каталог artifacts целевой сервис: app-replan-delivery.jar для первой задачи, app-ibank.jar для второй задачи.
6. Создайте публичный репозиторий на GitHub и свяжите свой локальный репозиторий с удалённым.
7. Сделайте пуш — удостоверьтесь, что ваш код появился на GitHub.
8. Выполните интеграцию проекта с Github Actions (инструкция) или Appveyor (инструкция) на выбор, удостоверьтесь что автотесты в CI выполняются.
9. Поставьте бейджик сборки вашего проекта в файл README.md.
10. Ссылку на ваш проект отправьте в личном кабинете на сайте netology.ru.
11. Задачи, отмеченные как необязательные, можно не сдавать, это не повлияет на получение зачёта.
12. Автотесты могут падать и сборка может быть красной из-за багов тестируемого приложения. В таком случае должны быть заведены репорты на обнаруженные в ходе тестирования дефекты в отдельных issues, придерживайтесь схемы при описании.

Настройка CI

Настройка CI осуществляется аналогично предыдущему заданию, за исключением того, что файл целевого сервиса может называться по-другому. Для второй задачи вам также понадобится указать нужный флаг запуска для тестового режима.

Задача №1: заказ доставки карты (изменение даты)

Вам необходимо автоматизировать тестирование новой функции формы заказа доставки карты:

Требования к содержимому полей, сообщения и другие элементы, по словам заказчика и разработчиков, такие же, они ничего не меняли.

Примечание: личный совет — не забудьте это перепроверить, никому нельзя доверять 😈

Тестируемая функциональность: если заполнить форму повторно теми же данными, за исключением «Даты встречи», то система предложит перепланировать время встречи:

После нажатия кнопки «Перепланировать» произойдёт перепланирование встречи:

Важно: в этот раз вы не должны хардкодить данные прямо в тест. Используйте Faker, Lombok, data-классы для группировки нужных полей и утилитный класс-генератор данных — см. пример в презентации.

Утилитными называют классы, у которых приватный конструктор и статичные методы.

Обратите внимание, что Faker может генерировать не совсем в нужном для вас формате.

Поскольку файлы с расширением .jar находятся в списках .gitignore, вам нужно принудительно
заставить Git следить за ними: git add -f artifacts/app-replan-delivery.jar.

Для запуска учебного сервиса, находясь в папке проекта, выполните в терминале команду

java -jar ./artifacts/app-replan-delivery.jar

Задача №2: тестовый режим

Разработчики интернет-банка, изрядно поворчав, предоставили вам тестовый режим запуска целевого сервиса, в котором открыта программная возможность создания клиентов банка, чтобы вы могли протестировать хотя бы функцию входа.

Для удобства вам предоставили документацию, которая описывает возможность программного создания клиентов банка через API. Вот дословно представленное ими описание:

Для создания клиента нужно делать запрос вида:

POST /api/system/users
Content-Type: application/json

{
    "login": "vasya",
    "password": "password",
    "status": "active" 
}

Возможные значения поля «Статус»:
* «active» — пользователь активен,
* «blocked» — пользователь заблокирован.

В случае успешного создания пользователя возвращается код 200.

При повторной передаче пользователя с таким же логином будет выполнена перезапись данных пользователя.

Давайте вместе разбираться. Мы уже проходили:

• клиент-серверное взаимодействие,
• HTTP-методы и коды ответов,
• формат данных JSON,
• REST-assured.

Мы настоятельно рекомендуем ознакомиться с документацией и примерами на Rest-assured.

Подключается обычным образом в Gradle:

testImplementation 'io.rest-assured:rest-assured:4.3.0'
testImplementation 'com.google.code.gson:gson:2.8.6'

Библиотека Gson нужна для того, чтобы иметь возможность сериализовать Java-объекты в JSON.

То есть мы не руками пишем JSON, а создаём data-классы, объекты которых и преобразуются в JSON.

Дальнейшее использование выглядит следующим образом:

// спецификация нужна для того, чтобы переиспользовать настройки в разных запросах
class AuthTest {
    private static RequestSpecification requestSpec = new RequestSpecBuilder()
        .setBaseUri("http://localhost")
        .setPort(9999)
        .setAccept(ContentType.JSON)
        .setContentType(ContentType.JSON)
        .log(LogDetail.ALL)
        .build();

    @BeforeAll
    static void setUpAll() {
        // сам запрос
        given() // "дано"
            .spec(requestSpec) // указываем, какую спецификацию используем 
            .body(new RegistrationDto("vasya", "password", "active")) // передаём в теле объект, который будет преобразован в JSON
        .when() // "когда" 
            .post("/api/system/users") // на какой путь относительно BaseUri отправляем запрос
        .then() // "тогда ожидаем"
            .statusCode(200); // код 200 OK
    }
    ...
}

Это не лучший формат организации, будет лучше, если, как в предыдущей задаче, вы вынесете это в класс-генератор, который по требованию вам будет создавать рандомного пользователя, сохранять его через API и возвращать вам в тест.

В логах теста вы увидите:

Request method:	POST
Request URI:	http://localhost:9999/api/system/users
Proxy:			<none>
Request params:	<none>
Query params:	<none>
Form params:	<none>
Path params:	<none>
Headers:		Accept=application/json, application/javascript, text/javascript, text/json
				Content-Type=application/json; charset=UTF-8
Cookies:		<none>
Multiparts:		<none>
Body:
{
    "login": "vasya",
    "password": "password",
    "status": "active" 
}

Для активации этого тестового режима при запуске SUT нужно указать флаг -P:profile=test, то есть: java -jar app-ibank.jar -P:profile=test.

Важно: если вы не активируете тестовый режим, любые запросы на http://localhost:9999/api/system/users будут вам возвращать 404 Not Found.

Вам нужно самостоятельно изучить реакцию приложения на различные комбинации случаев, для этого придётся вспомнить комбинаторику:

• наличие пользователя;
• статус пользователя;
• невалидный логин;
• невалидный пароль.

Дополнительно: оцените время, которое вы затратили на автоматизацию, и время, за которое вы проверили бы те же сценарии вручную, используя для тестирования интерфейса браузер и Postman для доступа к открытому API.

Приложите к решению задачи в формате:

• время, затраченное на ручное тестирование (минут): x;
• время, затраченное на автоматизацию (минут): y.

Подсказка

Не читайте этот раздел сразу, попытайтесь сначала решить задачу самостоятельно :)

Как подключить Lombok

Посмотрите видео «Lombok & Lambda» в уроке «Основы автоматизации».