Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

1 тест - 1 класс, или тесты над одним объектом можно помещать в один класс?


(Funker) #1

Инструменты:

Webdriver + Java + TestNG  c использование  PageObject + PageFactoty

Вопрос как правильно создавать тесты

  1. 1 класс  - 1 тест

  2. 1 класс  - 3 однотипных теста

Пример. Есть объект мы можем:

  • тест 1 -  создать

  • тест 2 -  отредактировать

  • тест 3 -  удалить

объектов может быть очень много и все подчиняются этим правилам, что лучше? что говорит опыт? создать на каждый класс отдельный тест  или все в один запихнуть?

Если нужно будет запустить группу тестов на удаление или создание так это можно будет в аннотациях для TestNG  указать

@Test (groups={ "Create Group Tests" })

@Test (groups={ "Edit Group Tests" })

@Test (groups={ "Delete Group Tests" })

 


(Sergey Korol) #2

Зависит от многих факторов: способа организации фреймворка, типа тестов, логической составляющей и т.п. Тут нет однозначного ответа - что лучше.

Вы можете объединить тесты в пакеты по логической составляющей. К примеру, пакет авторизации, в котором будут классы на тестирование логина, логаута, негативные тесты и т.п.  Причем классы будут называться по типу LoginTest, LogoutTest и т.п., а пакет - Authorization. В целом, при таком подходе некоторые тесты можно как объединить в 1 класс, так и оставить строгое разбиение 1:1. Т.е. по сути, такой вариант будет являться отражением вашего чеклиста. Открыв тесты, вы будете видеть, к какому логическому блоку функционала они относятся, сможете определить покрытие, проблемные области и т.п.

Либо вы можете создать пакеты с объектной привязкой. По типу UserOperations, а внутри 1 класс, содержащий в себе все манипуляции с юзерами - создание, редактирование, удаление.

Можно вообще запихнуть все классы в 1 пакет tests и идентифицировать функционал по имени класса, но при разрастании тестов сложно будет все это дело поддерживать.

В зависимости от выбора того или иного подхода возникает вопрос в типе запуска - как вы хотите, чтобы testng запускал тесты? По классам, по методам и т.п., при этом, сохраняя независимость самих тестов друг от друга.

В общем случае я бы рекомендовал использование первого варианта. Но тут еще есть нюанс в подходе к самому тестированию. Если ваши тесты строго ориентированы на проверку конкретных объектов с ограниченным набором функционала, и вы точно знаете, что ничего более вы проверять не собираетесь в будущем, то второй вариант будет выглядеть логичней.

Исходя из того, что полная картина нам не видна, то выбор нужного подхода, как говорится, - It's up to you.


(Mykhailo Poliarush) #3

самое главное правило, тесты должны быть максимално не зависимыми

потому, я вам рекомендую первый вариант

потому что второй подразумевает зависимость

но надо просто включить голову и здравый смысл, и решение придет само собой :)