testing - run - ¿Deben separarse sus especificaciones de BDD de sus pruebas de UI?

cucumber tags

Question

Ayer asistí a una gran presentación de Gojko Adzic sobre BDD. Puede que me haya perdido una o dos cosas, dijo, así que aquí hay una pregunta que con suerte me aclarará algunas cosas.

A menudo, cuando ves el ejemplo BDD en línea, han incluido pasos en la interfaz de usuario. En un idioma de pepinillo a menudo puedes ver algo como:

Scenario: Successful booking
    Given I am on the page ...
    When I enter the following ...

O algo así.

Mi pregunta es, ¿eso realmente tiene que ver con BDD? ¿No debería BDD dirigirse al dominio y luego tiene ese tipo de pruebas como UI o pruebas de regresión? Lo que estoy pensando es algo así como utilizar la sintaxis de pepinillo para describir algún tipo de sistema de reserva:

BDD Spec:

Scenario: Successful booking
    Given I am an authenticated user
    When I place an order with the following items
        | item  | price ($) |
        | book1 | 5         |
    Then I should expect to pay $5
    And I should get a confirmation mail of my order

Tenga en cuenta que no estoy mencionando la UI en absoluto, solo estoy describiendo cómo funciona el dominio y esta prueba debe ejecutarse en cada compilación. Luego puede tener su prueba de UI (también pepinillo):

Scenario: Successful booking
    Given I am logged in on the site
    And I go to the page for item book1
    And I click add to basket
    Then I should have a basket with 1 item and $5
    When I click checkout
    Then I should get to the checkout page

y continúa, tal vez debería separarse en dos o tres escenarios, pero ese no es el punto. Este tipo de pruebas son más pesadas para ejecutarse y probablemente solo se deberían ejecutar en compilaciones nocturnas. El punto de la pregunta es aún: ¿Debería separar las especificaciones BDD de su prueba de regresión / UI?

Answer 1

BDD se reduce a la colaboración entre otras personas no técnicas de QA con los desarrolladores que usan el lenguaje nativo como definiciones para la funcionalidad. Entonces, desde esta perspectiva, es probable que los interesados ​​entiendan ambos ejemplos como una característica.

Pero en general, cuanto más abstracto puedas hacer la "historia", mejor. La diferencia, o problema potencial, no se trata tanto de mencionar la interfaz de usuario, sino también posibles suposiciones y discusiones sobre el diseño. Es probable que el flujo de trabajo inicial de la aplicación cambie, por lo que los cambios en la definición de la característica podrían requerir nuevas discusiones con los usuarios. Conversaciones que tal vez no sean realmente necesarias si el objetivo sigue siendo el mismo.

Dicho esto, la practicidad entrará en juego muy rápidamente. Una definición de característica ambigua requerirá una definición más exacta para la interfaz de usuario, y que a su vez se convertirá en una definición de paso o pruebas escritas con otras herramientas de prueba de interfaz de usuario. Escribir las definiciones de pasos reales para los archivos de características es la parte más difícil, por lo que escribir nuevos escenarios es bastante rápido una vez que tenga un conjunto completo de definiciones de pasos en su lugar. No reutilizar estos en las pruebas de UI parece un desperdicio, por lo que usamos el mismo conjunto para las pruebas de UI.

Separamos las pruebas de UI solo en el sentido de que no todos los escenarios se discuten con los interesados. Los más importantes etiquetados, y cada característica tiene uno o dos scnearios etiquetados y el resto son pruebas de UI. Además, a veces los archivos de características no los escribe la persona que escribe las definiciones de paso, por lo que el escritor de pruebas de UI puede estar menos informado sobre los detalles de cómo se implementan las operaciones de IU en el marco en uso.

Answer 2

No se recomienda intentar separar las pruebas de dominio y UI.

La gran ventaja de utilizar Cucumber es que sus especificaciones (pruebas) pueden ser leídas y entendidas por partes interesadas no técnicas. Esas personas probablemente no están demasiado preocupadas por los detalles de la interfaz de usuario.

Entonces, un buen enfoque es simplemente empujar la interfaz de usuario hacia abajo una capa dentro de las definiciones de paso, por ejemplo

Given /^I place an order for "([^"]*)"$/ do |item|
  visit catalog_url
  click_link item
  click_button "Add To Basket"
  click_button "Submit Order"
end