Тест кейсы как код
Очень давно не писал заметок, так как блог в основном переехал в телеграм.
Сегодня расскажу о подходе использования Test cases as a code. Я уже очень давно думал о такой штуке, но не хватало опыта ее внедрения.
Что же такое тест кейсы как код? На старте проекта я задумался о том, как можно сократить время на написание тест кейсов. Плюс мне хотелось как-то контролировать создание тест кейсов и их правки. На проекте в качестве тест кейс менеджмент-системы используется Test Rail. С ним у меня опыта достаточно много, я писал интерграции для создания тест ранов и проставления статусов во время прогона тестов.
Однако у Test Rail есть один фатальный недостаток - сложно контролировать создание тест кейсов. Там нет такого понятия, как ревью. Мне же хотелось управлять процессом.
Решение оказалось достаточно простым. Вместо детальных тест кейсов было принято решение использовать чеклист. Пуктами чеклиста и есть наши методы автотестов.
@Test
void userCanLoginWithValidCredentails(){
LoginPage.open()
.enterPassword("admin")
.enterLogin("admin")
.pressLogin();
at(MainPage.class).userLoggedName.shouldHave(exactText("admin"));
}Сюда мы прикручиваем интеграцию с Test Rail, которая не запуская тестов вытаскивает нужную информацию и записывает ее в виде пункта чеклиста.
Остается одна проблема - не всегда проверки можно автоматизировать. Следовательно нужно было как-то документировать ручные проверки. Эту проблему я решил через аннотации.
@Test
@Manual({
@Case(title = "Check user login is disabled after three incorrect login attempts ", ac = "1")
})
void userCanLoginWithValidCredentails(){
LoginPage.open()
.enterPassword("admin")
.enterLogin("admin")
.pressLogin();
at(MainPage.class).userLoggedName.shouldHave(exactText("admin"));
}Теперь с помощью расширенного модуля интеграции с тест рейлом информация из этой аннотации вытаскивается и создается пункт чеклиста и помечается как ручной.
После проверки теории и стадии PoC последовало развитие идеи и реализация боевого решения. Мы добавили аннотации для связи с Jira. В итоге решение выглядит так:
@Epic("Login")
public class UserLoginTest {
@Test
@Manual({
@Case(title = "Check user login is disabled after three incorrect login attempts ", ac = "1")
})
@Jira(id="Jira-567", title="User is able to to the system login")
void userCanLoginWithValidCredentails(){
LoginPage.open()
.enterPassword("admin")
.enterLogin("admin")
.pressLogin();
at(MainPage.class).userLoggedName.shouldHave(exactText("admin"));
}
}Для генерации тест кейсов была написана gradle задача. Генерация выполняется прямо из IDE с помощью вызова ./gradlew syncTestRail.
Что мы получили в итоге?
Все тест кейсы у нас хранятся в коде и проходят ревью точно так же, как и код. У всех аккаунтов в тест рейле есть право только на просмотр, таким образом никто не может внести изменения, кроме как через код. Единственной точкой правды является сорс код автоматизированных тестов. Модуль интеграции расширен и теперь во время прогона тестов есть возможность автоматически создавать тест ран на основе запускаемых тестов и проставлять статусы соотвествующим тестам. Мы сократили уровень ручной работы до нулевого, повысили прозрачность процесса. Надеюсь, мой опыт поможет вам сделать что-то подобное. Оставайтесь на связи, подписывайтесь на телеграм канал.