¿Cómo contrarrestar el anti-patrón BDD-scripting en Specflow?

Question

Este es un ejemplo de una de nuestras pruebas de aceptación:

Feature: Add an effect to a level 
In order to create a configuration 
As a user 
I want to be able to add effects to a level 

Scenario: Add a new valve effect to a level 
Given I have created a level named LEVEL123 with description fooDescription 
And I am on the configuration page 
When I click LEVEL123 in the level tree 
And I expand the panel named Editor Panel 
And I click the Add Valve Effect button 
And the popup named ASRAddVal appears 
And I click the Add new button 
And I fill in these vertical fields 
    | field name | value    | 
    | Name  | Effect123   | 
Then I should see the following texts on the screen 
    | text      | 
    | Effect added : EFFECT123 | 

Creemos que esto se está poniendo un poco para detallado y queremos escuchar cómo reducir los pasos en Specflow. Por lo que he leído hasta ahora, no se recomienda crear pasos específicos no reutilizables, entonces, ¿qué se considera "mejor práctica" al hacer esto en SpecFlow?

Actualización:

Lo que estoy tratando de decir es que he aprendido que usted debe tratar de crear pasos genéricos con el fin de volver a utilizarlos a través de múltiples pruebas. Una forma de hacerlo es parametrizar sus pasos, por ejemplo: "Dado que he creado un nivel llamado ...", pero la parametrización también introduce verbosidad. Quiero terminar con algo que Bryan Oakley sugiere en su respuesta, pero simplemente no puedo ver cómo puedo hacerlo sin crear pasos que sean muy específicos para cada prueba. Esto significa que terminaré con muchos pasos que reducen el mantenimiento. Parece que SpecFlow tiene alguna forma de definir los pasos abreviados al crear un archivo que hereda una clase base llamada "Pasos", pero esto aún introduce nuevos pasos.

Para resumir las cosas; muéstrame un buen enfoque para terminar con la respuesta de Bryan Oakleys, que es mantenible.

Answer 1

que simplificaría a algo como esto:

Scenario: Add a new valve effect to a level 
Given I have created a new level 
When I add a new valve effect with the following values 
    | field name | value    | 
    | Name  | Effect123   | 
Then I should get an on-screen confirmation that says "Effect added: Effect123" 

La forma más me acercaba al problema era imaginar que se está rediseñando completamente la interfaz de usuario. ¿Sería la prueba aún utilizable? Por ejemplo, la prueba debería funcionar incluso si no hay un botón "Agregar" en el rediseño, o si ya no usa una ventana emergente.

Answer 2

Puede tratar de redactarlos genéricamente y usar parámetros.

Given i have create a new: Level 

':' es solo para que pueda identificar el parámetro. Esto significa que tendría un punto de entrada genérico para un paso que necesita crear algo nuevo. Es hasta el siguiente paso para mirar el parámetro de nivel y crear un nuevo nivel

También intente crear una conversión de nombres que todos puedan usar. Debería ser fácil descubrir qué pasos ya se han creado para que no obtenga pasos duplicados similares.

Answer 3

¿Puedo sugerir que tal vez el código que está probando debería pasar a pruebas unitarias? Tal vez lo que quiere decir con "prueba específica" son pruebas de unidades individuales que no están cubiertas por sus pruebas de aceptación.

Sólo un pensamiento :)