piramide - ¿Definiciones de pasos de ámbito de funciones con SpecFlow?
piramide de pruebas (6)
Estoy usando SpecFlow para hacer algunas pruebas de estilo BDD. Algunas de mis características son las pruebas de interfaz de usuario, por lo que utilizan WatiN. Algunos no son pruebas de UI, por lo que no lo hacen.
En este momento, tengo un solo archivo StepDefinitions.cs , que cubre todas mis características. Tengo un paso BeforeScenario que inicializa WatiN. Esto significa que todas mis pruebas inician Internet Explorer, ya sea que lo necesiten o no.
¿Hay alguna forma en SpecFlow de tener un archivo de características particular asociado con un conjunto particular de definiciones de pasos? ¿O me estoy acercando a esto desde el ángulo equivocado?
Actualmente (en SpecFlow 1.3) las definiciones de pasos son globales y no pueden ser objeto de funciones particulares.
Esto es por diseño para tener el mismo comportamiento que el pepino.
Le hice la misma pregunta al grupo de pepinos:
La línea de base es que el lenguaje definido por todos los archivos de características también debe ser global (un comportamiento global de toda la aplicación). Por lo tanto, deben evitarse las definiciones de alcance a las características. Personalmente todavía no estoy completamente convencido de esto ...
Sin embargo, su problema con el inicio de WatiN solo para los escenarios que requieren integración con UI se puede resolver de dos maneras diferentes:
Etiquetas y enlaces etiquetados: puede etiquetar sus escenarios (es decir, con @web) y definir en un enlace Antes del Escenario que solo debería ejecutarse para los escenarios con una etiqueta determinada (es decir, [Antes del Escenario ("web")]). Consulte la integración de Selenium en nuestro ejemplo de BookShop: http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs
A menudo, separamos por completo los escenarios que están vinculados a la interfaz de usuario y los escenarios que están vinculados a una API programática (es decir, controlador, modelo de vista ...) en diferentes proyectos. Tratamos de ilustrar esto en nuestro ejemplo de BookShop: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/ .
Hay una solución simple para su problema si usa etiquetas.
La primera etiqueta en su archivo de características para indicar que una característica en particular necesita WatiN así:
Feature: Save Proportion Of Sample Pool Required As an <User> I want to <Configure size of the Sample required> so that <I can advise the deployment team of resourcing requirments>. @WatiN Scenario: Save valid sample size mid range Given the user enters 10 as sample size When the user selects save Then the value is stored
Y luego decorar el enlace BeforeScenario con un atributo que indica la etiqueta:
[BeforeScenario("WatiN")]
public void BeforeScenario()
{
...
}
Este método BeforeScenario solo se llamará para las funciones que usan WatiN.
La solución para esto es implementar Tags & Scoped Binding con el escenario de prueba relacionado con la web o relacionado con la lógica del Controlador / Núcleo en el código.
Y profundice el alcance de cada escenario en cualquiera de las ejecuciones anteriores / posteriores mencionadas a continuación.
BeforeTestRunScenario
BeforeFeature
BeforeScenario
BeforeScenarioBlock
BeforeStep
AfterStep
AfterScenarioBlock
AfterScenario
AfterFeature
AfterTestRunScenario
Mira esto (nueva función en SpecFlow 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings
Originalmente asumí que un archivo de pasos estaba asociado con un archivo de características en particular. Una vez que me di cuenta de que esto no era cierto, me ayudó a mejorar todos mis archivos de características y código SpecFlow. El lenguaje de mis archivos de características ahora depende menos del contexto, lo que ha dado como resultado definiciones de pasos más reutilizables y menos duplicación de código. Ahora organizo mis archivos de pasos de acuerdo con las similitudes generales y no de acuerdo con qué función son para ellos. Por lo que sé, no hay manera de asociar un paso con una característica en particular, pero no soy un experto en SpecFlow, así que no confíe en mi palabra.
Si aún desea asociar sus archivos de pasos con un archivo de características en particular, simplemente deles nombres similares. No es necesario que se vea forzado a trabajar solo para esa función, incluso si el código de paso solo tiene sentido para esa característica. Esto se debe a que incluso si creas un paso duplicado para una característica diferente, detectará esto como una coincidencia ambigua. El comportamiento para coincidencias ambiguas se puede especificar en un archivo App.config. Consulte http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf para obtener más detalles sobre el archivo App.config. Por defecto, las coincidencias ambiguas se detectan y se informan como un error.
[editar]: En realidad, hay un problema con el trabajo de esta manera (tener archivos de pasos asociados con archivos de características solo en tu mente). El problema se presenta cuando agrega o modifica un archivo .feature y usa la misma redacción que usó anteriormente, y olvida agregarle un paso, pero no lo nota porque ya creó un paso para esa redacción una vez antes. , y fue escrito de manera sensible al contexto. Además, ya no estoy convencido de la utilidad de no asociar archivos de pasos con archivos de características. No creo que la mayoría de los clientes sean muy buenos para escribir la especificación de manera independiente del contexto. No es así como normalmente escribimos, hablamos o pensamos.
También considere usar el DSL independiente de la implementación junto con las definiciones de los pasos específicos de la implementación. Por ejemplo, use
When I search for ''Barbados''
en lugar de
`Cuando escribo ''Barbados'' en el campo de búsqueda y presiono el botón Buscar
Al implementar conjuntos de definición de pasos múltiples, el mismo escenario puede ejecutarse a través de diferentes interfaces. Utilizamos este enfoque para probar las interfaces de usuario, API, etc. utilizando el mismo escenario.