Пишем автотесты с умом

TMS - это testcase managment system или если по-русски система управления тест-кейсами. Это очень полезный инструмент для ручного тестирования. На TMS можно ориентироваться и при написании автотестов. С помощью него можно запускать тестовые раны и тесткейсы. TMS можно интегрировать с автотестами. Как использовать TMS с автотестами и всегда ли нужно это делать?

Тема доклада: Автоматизация тестирования под Android с нуля до нескольких тысяч тестов. В нем я расскажу о том, как с нуля построить автоматизацию тестирования мобильных приложений под Android на примере компании Яндекс.Вертикали. Я отвечу на основные вопросы, которые при этом могут возникать, а также рассмотрю два инструмента, с которыми я работал Appium и Espresso.

Тема моего доклада: “Swagger/OpenAPI Specification как основа для ваших приемочных тестов”. В нем я расскажу как мы в Яндекс.Вертикалях построили процесс приемочного тестирования REST-API сервисов, в качестве основы взяв OAS спецификацию и как нам удается поддерживать автотесты на несколько десятков backend-ов с разной кодовой базой, которые активно развиваются, и легко добавлять автотесты на новые проекты. Heisenbug - одна из тех конференций для тестирований, которые мне действительно нравятся и в которой я уже давно хотел поучаствовать в роли спикера. В этом году ее из-за короновируса перенесли в онлайн режим. Очень интересно, что из этого получится.

У allure есть огромное количество интеграций для разных языков и фреймворков, в том числе и для scalatest - наиболее популярного тестового фреймворка для scala. Совсем недавно я добавил поддержку для allure-scalatest версии 2.13 к уже существующей 2.12. Я коротко расскажу как подключать и использовать allure-scalatest.

Swagger-coverage это инструмент для анализа, который нужен для получения картины о “покрытии” регрессионными тестами на основе OAS 2 (Swagger). Говоря о покрытии, имеется ввиду не функциональсть, а именно наличие вызовов с определенными API методами, параметрами и получение всех кодов ответов, которые соответсвуют спецификации тестируемого API.

Несмотря на то что espresso в первую очередь нацелен на разработчиков, сами тесты можно сделать более дружелюбными и удобными как для ручного тестирования, так и для людей никак с тестированием не связанных. Это можно сделать как с точки зрения кода, так и с точки зрения запуска почти без использования сторонних библиотек. Поэтому представляю пять простых способов сделать espresso тесты лучше.

Регрессионные тесты на REST API нужны для того, чтобы проверять, что новые изменения(добавление нового функционала, рефакторинг старого) не ломают старую функциональность. Тесты относительно (UI тестов) быстрые, так как работают на низком уровне по протокоу HTTP и требуют меньше правок из-за редких изменений API, так как для API важна обратная совместимость. Чаще всего они лежат рядом с кодом продукта и запускаются для каждого нового билда. В идеале запуск таких тестов является частью CI и происходит после сборки и установки тестируемого сервиса на тестовый стенд.

AssertJ - это assertJ-core, а также множество связанных с ним opensource библиотек и инструментов, которые позволяют гибко работать с assertions над типизированными объектами. AssertJ обладает большим количеством возможностей, на нее легко перевести проект, есть плагины генерации assertions по классам, а так же существует allure интеграция.

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

JOOQ (Java Object Oriented Querying) - open source инструмент с кодогенерацией для работы с SQL в Java. Из коробки JOOQ предоставляет удобный DSL для составления запросов, а также генератор классов на основе метаданных ДБ.