Знает ли огурец / корнишон что-то вроде концепции Gauge? - PullRequest
0 голосов
/ 06 марта 2020

Я использовал Gauge некоторое время, и у них есть идея концепции , которая определяется как «Концепции предоставляют возможность объединять повторно используемые логические группы шагов в одну единицу. Концепция представляет краткое изложение бизнес-намерений путем объединения логических групп шагов "( Документация по калибровочным параметрам ).

При этом можно легко сгруппировать несколько шагов и повторно использовать их как один шаг в другом тесте. case.

Мне было интересно, есть ли у Cucumber / Gherkin что-нибудь подобное?

Фон в том, что у меня есть контрольный пример end2end, который содержит несколько утверждений между ними, которые мне нравится распутывать и создавать несколько сценариев ios. Но тогда у меня будет несколько сценариев ios с дублированными шагами - я бы хотел сгруппировать соответствующие и минимизировать отдельные шаги внутри соответствующего сценария ios.

Спасибо :))

Ответы [ 2 ]

0 голосов
/ 10 марта 2020

В Gherkin вы просто создаете определение шага для своей группы шагов и используете его так же, как на человеческом языке. Пример Ruby, приведенный ниже, иллюстрирует повторное использование При наличии «действительного пользователя» в При условии «пользователь находится на странице входа» ,

Given /^a valid user$/ do
  @user = User.create!({
             :email => "example@gmail.com",
             :password => "password"
           })
end
Given /^user is on the login page$/ do
  Given "a valid user"
  visit signin_url
end
When /^user fills in Username with (.*?)/ do |username|
  fill_in "Email", :with => username
end
And /^user fills in Password with (.*?)$/ do |password|
  fill_in "Password", :with => password
end
And /^user presses "Login"$/ do 
  click_button "Sign in"
end
Then /^user should be on the users home page$/ do 
  assert_equal (getCurrentUrl(), 
  "https://www.linkedin.com/feed/")
end
0 голосов
/ 06 марта 2020

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

С другой стороны, огурец облегчает BBD, и вы используете Gherkin для захвата поведения системы, а не операций в тесте. Таким образом, вместо написания Login as user "Charles: and create project "Firebird", который описывает операции, которые вы пишете, Given Administrator "Charles" created the project "Firebird".

Это довольно резкий сдвиг в перспективе, но помогает четко понять, что должно делать программное обеспечение, а не то, как оно должно работать .

В результате вы обычно избегаете писать операции низкого уровня в Gherkin. Скорее вы извлекаете их в методы и вызываете эти методы со своего шага. Затем вы можете также использовать эти методы в других шагах.

Например, предположим, что у нас есть два шага для создания пользователя:

  • Given Administrator "Charles" created the project "Firebird"
  • And "Jullia" is added to project "Firebird"
@Given("{role} {persona} created the project {project}")
public void persona_with_role_creates_a_project(Role role, Persona persona, Project project){
    createRole(role);
    createUserForPersona(persona);
    addRoleToUserForPersona(persona, role);
    loginUserForPersona(persona);
    createProject(project);
}

@And("{persona} is added to project {project}")
public void persona_with_role_creates_a_project(Persona persona, Project project){
    createUserForPersona(persona);
    addUserForPersonaToProject(persona, project);
}


@ParameterType("\"([^"]+)\"")
public Persona persona(String name){
   // look up the persona by name from somewhere e.g. a config file
}

ect...

private void createRole(Role role){
    // API calls to make a role here
    // For test isolation it is important you don't reuse anything between tests.
}

private void createUserForPersona(Persona persona){
   // API calls to create a user
   // Don't forget to store the credentials for the persona somewhere
}

ect..

Обратите внимание, что для создания пользователя и проекта может потребоваться достаточно много информации. Поэтому вместо того, чтобы записывать всю эту информацию в файле возможностей, мы ссылаемся на персонажей ("Charles", "Firebird"), которые действуют как шаблоны для типа проекта, который мы создаем. Мы можем предоставить их объектам определений шагов, а не простым строкам, используя типы параметров ({persona}, {project}). Они преобразуют строку в объект до выполнения шага.

...