Este artículo proviene de un motor de traducción automática.
BDD Primer
Desarrollo controlado por comportamiento (Behavior-Driven Development, BDD) con SpecFlow y WatiN
Brandon Satrom
Descargar el código de ejemplo
A medida que se convierte en las pruebas de unidades automática más ubicuo en el desarrollo de software, aumenta la adopción de diversos métodos de la primera prueba. Estas prácticas presentan un conjunto único de las oportunidades y desafíos a los equipos de desarrollo, pero todos se esfuerzan por establecer una mentalidad “ pruebas como diseño ” con profesionales.
Para la mayor parte de la era de la primera prueba, sin embargo, el método para expresar el comportamiento de un usuario ha sido a través de la unidad de prueba escrita en el idioma del sistema, un lenguaje que se desconectó el usuario. Con la llegada de las técnicas de desarrollo Behavior-Driven (BDD), está cambiando este dinámicos. Mediante técnicas de BDD, que se puede crear automatiza las pruebas en el lenguaje de la empresa, al tiempo que mantiene una conexión con el sistema implementado.
Por supuesto, se han creado varias herramientas para facilitar la implementación de BDD en el proceso de desarrollo. Incluye pepino Ruby y SpecFlow y WatiN para Microsoft .NET Framework. SpecFlow le ayuda a escribir y ejecutar las especificaciones de Visual Studio, mientras que WatiN permite que el explorador para la prueba sistema automática de extremo a extremo de la unidad.
En este artículo, va a proporcionar una breve introducción de BDD y, a continuación, explique cómo el ciclo BDD ajusta el ciclo de desarrollo Test-Driven (TDD) tradicional con las pruebas de nivel de función que nivel de unidad de la aplicación de unidad. Una vez que he definido el marco de trabajo para los métodos de prueba a la primera, lo almacenaré presentar SpecFlow y WatiN y se muestran algunos ejemplos de cómo se pueden utilizar estas herramientas con MSTest para implementar BDD para los proyectos.
Una historia de la prueba automática
Una de las prácticas más valiosas que surgen con el movimiento de software ágil es un estilo de desarrollo automatizado, prueba a la primera, que se denomina a menudo Test-Driven desarrollo o TDD. Un principio clave de TDD es que la creación de la prueba es tanto relacionados con la Guía de diseño y desarrollo, comprobación y regresión. Se trata también el uso de la prueba para especificar una unidad de la funcionalidad necesaria y el uso de esa prueba, a continuación, escribir sólo el código necesario para ofrecer esa funcionalidad. Por tanto, el primer paso para implementar ninguna funcionalidad nueva es describir sus expectativas con un error de prueba (consulte de figura 1).
.jpg)
Figura 1 del ciclo de desarrollo controlado por la prueba
Muchos equipos y los desarrolladores han tenido éxito con TDD. Otros no y encontrar tienen dificultades con la administración del proceso con el tiempo, especialmente en el volumen de las pruebas empieza a crecer y la flexibilidad de las pruebas se empieza a degradarse. Otros no seguro de cómo iniciar con TDD, mientras que otros usuarios encontrar TDD fácil para iniciar, sólo para ver que lo abandona como las fechas límite que parecen casi y grandes acumulaciones. Por último, muchos desarrolladores interesados satisfacen resistencia a la sesión de práctica en su organización, ya sea porque la palabra “ prueba ” implica una función a la que pertenece a otro equipo o debido a la percepción de false que da como resultado demasiado código adicional de TDD y reduce la velocidad de proyectos.
Steve Freeman y Pryce de Nat, en su libro, “ software orientadas a objetos de crece, guiada por las pruebas ” (Addison-Wesley Professional, 2009), nota que TDD “ tradicional ” pierde algunas de las ventajas del desarrollo de prueba a la primera es true:
“ Resulta tentador para iniciar el proceso de TDD escribiendo las pruebas unitarias para las clases de la aplicación. Esto es mejor que si no hay pruebas en absoluto y puede detectar los errores de programación básicas que todos conocemos pero por lo tanto, difícil de evitar … de la búsqueda, pero es de un proyecto con las pruebas unitarias sólo falta out en importantes ventajas del proceso de TDD. Hemos visto proyectos con alta calidad, bien probado de unidad que no resultó fuera para llamarse desde cualquier parte de código, o que podría no estar integrado con el resto del sistema y tuvo que volver a escribir. ”
En 2006, Dan Norte había documentado muchos de estos desafíos en un artículo en Mejor Software revista (blog.dannorth.net/introducing-bdd ). En su artículo, Norte describe una serie de prácticas que había adoptado sobre el antes de tres años, mientras que en las trincheras con las pruebas. Mientras sigue TDD por definición, estas prácticas norte por adoptar una vista más centrada en análisis de las pruebas y el término Behavior-Driven de desarrollo para encapsular este cambio de moneda.
Una aplicación más popular de BDD intenta ampliar TDD al apretar el foco y el proceso de creación de pruebas a través de las pruebas de aceptación o las especificaciones de archivo ejecutables. Cada especificación sirve como punto de entrada en el ciclo de desarrollo y describe, desde punto de vista su y en un formulario de paso a paso, cómo debe comportarse el sistema. Una vez que escribe, el desarrollador utiliza la especificación y su proceso de TDD existente para implementar suficiente código de producción para producir un escenario de transferencia (consulte de figura 2).
.jpg)
La figura 2 del ciclo de desarrollo controlada por el comportamiento
Donde comienza el diseño
BDD considera muchos un superconjunto de TDD, no un reemplazo para el mismo. La diferencia principal es el enfoque en la creación inicial de diseño y pruebas. En lugar de centrarse en las pruebas de unidades o los objetos, al igual que con TDD, me centro en los objetivos de los usuarios y los pasos que seguir para alcanzar esos objetivos. Debido a que ya no estoy empezando con las pruebas de unidades pequeñas, me llamo menos inclinada a speculate en detalles más granulares de uso o diseño. En su lugar, estoy documentar las especificaciones de archivo ejecutables que probar mi sistema. Escribir pruebas unitarias todavía, pero BDD fomenta un enfoque en el exterior que comienza con una descripción completa de la característica de implementación.
Let’s consultar un ejemplo de la diferencia. En una práctica de TDD tradicional, se puede escribir la prueba en de figura 3 para utilizar el método de creación de un CustomersController.
La figura 3 de la prueba de unidades para la creación de un cliente
[TestMethod]
public void PostCreateShouldSaveCustomerAndReturnDetailsView() {
var customersController = new CustomersController();
var customer = new Customer {
Name = "Hugo Reyes",
Email = "hreyes@dharmainitiative.com",
Phone = "720-123-5477"
};
var result = customersController.Create(customer) as ViewResult;
Assert.IsNotNull(result);
Assert.AreEqual("Details", result.ViewName);
Assert.IsInstanceOfType(result.ViewData.Model, typeof(Customer));
customer = result.ViewData.Model as Customer;
Assert.IsNotNull(customer);
Assert.IsTrue(customer.Id > 0);
}
Con TDD, esto suele ser una de las primeras pruebas que escribo. Diseña una API pública para mi objeto CustomersController estableciendo sus expectativas sobre cómo se comportará. Con BDD aún se crea la prueba, pero no al principio. En su lugar, eleve el enfoque a la funcionalidad de nivel de la función escribiendo algo más como de figura 4. A continuación, utilizo este escenario como guía para la implementación de cada unidad de código necesario para realizar este escenario se pasa.
La figura 4 de especificación de nivel de función
Feature: Create a new customer
In order to improve customer service and visibility
As a site administrator
I want to be able to create, view and manage customer records
Scenario: Create a basic customer record
Given I am logged into the site as an administrator
When I click the "Create New Customer" link
And I enter the following information
| Field | Value |
| Name | Hugo Reyes |
| Email | hreyes@dharmainitiative.com |
| Phone | 720-123-5477 |
And I click the "Create" button
Then I should see the following details on the screen:
| Value |
| Hugo Reyes |
| hreyes@dharmainitiative.com |
| 720-123-5477 |
Éste es el bucle externo en figura 2 , la falta de prueba de aceptación. Una vez que esta prueba se ha creado y se produce un error, implementar cada paso de cada escenario en Mi característica siguiendo el bucle interno de TDD representado en de figura 2. En el caso de que la CustomersController en de figura 3, escribiré esta prueba una vez que alcance el paso correcto en la función, pero antes de que implemente la lógica del controlador necesaria para realizar este paso pasar.
BDD y la prueba automática
Desde el principio, la Comunidad de BDD ha procurado ofrecer el mismo nivel de pruebas automatizadas con las pruebas de aceptación que ha sido la norma en la unidad de pruebas durante algún tiempo. Un ejemplo más significativa es pepino (cukes.info de ), una herramienta de prueba basada en Ruby que acentúa la creación de las pruebas de aceptación de nivel de la función escrita en “ legible para el negocio, específicos de dominio de lenguaje. ”
Las pruebas de pepino se escriben con sintaxis de la historia de usuario para cada archivo de la función y un dado, cuándo, sintaxis de Then GWT () para cada escenario. (Para obtener más información sobre la sintaxis de la historia de usuario, consulte c2.com/cgi/wiki?UserStory de ). GWT describe el contexto actual de la situación de ejemplo (dado), las acciones realizadas como parte de la prueba (al) y los resultados esperados, observables (Then). La característica de del 4 de la figura es un ejemplo de sintaxis de este tipo.
En pepino, se analizan los archivos de la función legible por el usuario y cada paso de escenario está asociado a Ruby código que haga uso de las interfaces públicas del sistema en cuestión y determina si ese paso tiene éxito o falla.
En los últimos años, lo que permite el uso de escenarios como pruebas automáticas de innovaciones han ampliado en el ecosistema de .NET Framework. Los programadores ahora tienen herramientas que permiten a las especificaciones que se escriban con que la misma estructura de sintaxis inglés que pepino utiliza y, a continuación, que puede utilizar las especificaciones como pruebas que ejecutan el código. Herramientas como SpecFlow (specflow.orgde ), de prueba de BDD Cuke4Nuke (github.com/richardlawrence/Cuke4Nuke ) y otros usuarios le permiten crear especificaciones de archivo ejecutables en primer lugar en el proceso, aprovechar esas especificaciones que la funcionalidad de generación y terminar con una función documentada en el que está relacionada directamente con el desarrollo y el proceso de prueba.
Introducción a SpecFlow y WatiN
En este artículo, va a utilizar SpecFlow para probar una aplicación de Model-View-Controller (MVC). Para empezar a trabajar con SpecFlow, primero deberá descargar e instalar en él. Una vez instalado SpecFlow, cree una nueva aplicación de ASP.NET MVC con un proyecto de prueba de unidad. Yo prefiero que mi proyecto de prueba de la unidad contiene sólo pruebas unitarias (controlador de pruebas, las pruebas del repositorio y así sucesivamente), por lo que también creo un proyecto de prueba AcceptanceTests para mis pruebas SpecFlow.
Una vez que se ha agregado un proyecto de AcceptanceTests y agrega las referencias al ensamblado TechTalk.SpecFlow, agregar la nueva función mediante el Agregar | nuevo elemento de plantillas que SpecFlow crea en la instalación y asígnele el nombre CreateCustomer.feature.
Tenga en cuenta que el archivo se crea con la extensión .feature, y que Visual Studio reconoce como un archivo compatible, gracias a conjunto de herramientas integrada del SpecFlow. También puede observar que el archivo de la función tiene un archivo de código subyacente .cs relacionados. Cada vez que guarde un archivo .feature, SpecFlow analiza el archivo y el texto en ese archivo en un accesorio de prueba. El código en el archivo .cs asociado representa esa accesorio de prueba, que es el código que realmente se ejecuta cada vez que ejecute el conjunto de pruebas.
De forma predeterminada, SpecFlow usa NUnit como su ejecutor de pruebas, pero también admite MSTest con un cambio de configuración sencilla. Todo lo que debe hacer es agregar un archivo app.config al proyecto de prueba y agregue los siguientes elementos:
<configSections>
<section name="specFlow"
type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<unitTestProvider name="MsTest" />
</specFlow>
La primera prueba de aceptación
Cuando se crea una nueva característica, SpecFlow rellena dicho archivo con el texto predeterminado para ilustrar la sintaxis utilizada para describir una función. Reemplace el texto predeterminado en el archivo CreateCustomer.feature con el texto en de figura 4.
Cada archivo de la función tiene dos partes. La primera parte es el nombre de la función y la descripción en la parte superior, que utiliza la sintaxis de la historia de usuarios para describir la función de usuario, objetivo su y los tipos de acciones que el usuario debe ser capaz de realizar para alcanzar ese objetivo en el sistema. En esta sección se requiere SpecFlow para las pruebas de generación automática, pero no se utiliza el mismo contenido en las pruebas.
La segunda parte de cada archivo de la función es uno o varios escenarios. Cada escenario se utiliza para generar un método de prueba en el asociado. feature.cs archivo, como se muestra en de figura 5 y cada paso en un escenario se pasa para el ejecutor de pruebas SpecFlow, que lleva a cabo una coincidencia basada en RegEx del paso en una entrada en un archivo SpecFlow llamada a un archivo de definición de paso.
Método de prueba de la figura 5 generado por SpecFlow
public virtual void CreateABasicCustomerRecord() {
TechTalk.SpecFlow.ScenarioInfo scenarioInfo =
new TechTalk.SpecFlow.ScenarioInfo(
"Create a basic customer record", ((string[])(null)));
this.ScenarioSetup(scenarioInfo);
testRunner.Given(
"I am logged into the site as an administrator");
testRunner.When("I click the \"Create New Customer\" link");
TechTalk.SpecFlow.Table table1 =
new TechTalk.SpecFlow.Table(new string[] {
"Field", "Value"});
table1.AddRow(new string[] {
"Name", "Hugo Reyesv"});
table1.AddRow(new string[] {
"Email", "hreyes@dharmainitiative.com"});
table1.AddRow(new string[] {
"Phone", "720-123-5477"});
testRunner.And("I enter the following information",
((string)(null)), table1);
testRunner.And("I click the \"Create\" button");
TechTalk.SpecFlow.Table table2 =
new TechTalk.SpecFlow.Table(new string[] {
"Value"});
table2.AddRow(new string[] {
"Hugo Reyes"});
table2.AddRow(new string[] {
"hreyes@dharmainitiative.com"});
table2.AddRow(new string[] {
"720-123-5477"});
testRunner.Then("I should see the following details on screen:",
((string)(null)), table2);
testRunner.CollectScenarioErrors();
}
Una vez que haya definido la primera función, presione Ctrl + R, T para ejecutar las pruebas de SpecFlow. Debido a que SpecFlow no se puede encontrar una definición de paso coincidente para el primer paso en la prueba de la prueba CreateCustomer se producirá un error como no concluyentes (consulte de figura 6). Tenga en cuenta cómo se notifica la excepción en el archivo .feature real, que el archivo de código subyacente.
.jpg)
La figura 6 de SpecFlow no se puede encontrar una definición de paso
Debido a que aún no ha creado un archivo de definición de paso, se espera que esta excepción. Haga clic en Aceptar en el cuadro de diálogo de excepción y busque la prueba CreateABasicCustomerRecord en la ventana de resultados de pruebas de Visual Studio. Si no se encuentra un paso coincidente, SpecFlow utiliza el archivo de la función para generar el código que necesario en el archivo de definición de paso, que se puede copiar y utilizar para empezar a implementar esos pasos.
En el proyecto AcceptanceTests, cree un archivo de definición de paso con la plantilla de definición de paso SpecFlow y asígnele el nombre CreateCustomer.cs. A continuación, copie el resultado de SpecFlow en la clase. Observe que cada método contiene un atributo SpecFlow que designa el método como un dado, cuándo o Then paso y proporciona el objeto RegEx que se utiliza para que coincida con el método a un paso en el archivo de la función.
La integración de WatiN para probar el explorador
Parte de los objetivos con BDD es crear un conjunto de pruebas automatizadas que ejerce la mayor cantidad posible de la funcionalidad del sistema de end-to-end. Como estoy construyendo una aplicación de ASP.NET MVC, puedo utilizar herramientas que ayudan a la secuencia de comandos en el Explorador de Web para interactuar con el sitio.
Una de estas herramientas es una biblioteca de código abierto para la automatización de prueba de explorador Web, WatiN. Puede descargar WatiN watin.sourceforge.net de y agregar una referencia a WatiN.Core al proyecto las pruebas de aceptación para utilizarlo.
La forma principal de interacción con WatiN es a través de un objeto de explorador, ya sea IE() o FireFox(), dependiendo de su explorador preferido, que proporciona una interfaz pública para controlar una instancia de un explorador instalado. Debido a que tiene que recorrer el explorador a través de varios pasos en un escenario, necesitará una manera de pasar el mismo objeto de explorador entre los pasos de la clase de la definición de paso. Para controlar esto, suele crea una clase estática de WebBrowser como parte de mi proyecto AcceptanceTests y utiliza esa clase para trabajar con el objeto de Internet Explorer de WatiN y la ScenarioContext que SpecFlow se utiliza para almacenar el estado entre los pasos en un escenario:
public static class WebBrowser {
public static IE Current {
get {
if (!ScenarioContext.Current.ContainsKey("browser"))
ScenarioContext.Current["browser"] = new IE();
return ScenarioContext.Current["browser"] as IE;
}
}
}
El primer paso que es necesario implementar en CreateCustomer.cs es el paso dado, que comienza la prueba por el usuario de inicio de sesión en el sitio como administrador:
[Given(@"I am logged into the site as an administrator")]
public void GivenIAmLoggedIntoTheSiteAsAnAdministrator() {
WebBrowser.Current.GoTo(http://localhost:24613/Account/LogOn);
WebBrowser.Current.TextField(Find.ByName("UserName")).TypeText("admin");
WebBrowser.Current.TextField(Find.ByName("Password")).TypeText("pass123");
WebBrowser.Current.Button(Find.ByValue("Log On")).Click();
Assert.IsTrue(WebBrowser.Current.Link(Find.ByText("Log Off")).Exists);
}
Recuerde que la parte determinada de un escenario para configurar el contexto de la prueba actual. Con WatiN, puede que la unidad de prueba y interactuar con el explorador para implementar este paso.
Este paso, uso WatiN para abrir Internet Explorer, desplácese hasta la página de inicio de sesión del sitio, rellene el nombre de usuario y los cuadros de texto contraseña y, a continuación, haga clic en el botón Iniciar sesión en la pantalla. Cuando vuelva a ejecutan las pruebas, se abrirá automáticamente la ventana de Internet Explorer y que interactúa con el sitio WatiN puede observar en acción, haga clic en vínculos y escritura de texto (vea de figura 7).
.png)
La figura 7 del Explorador de piloto automático con WatiN
Ahora se pasará el paso dado y soy un paso más cerca de implementar la característica. Errores de SpecFlow será ahora en la primera cuándo el paso debido a que aún no se ha implementado el paso. Se puede implementar con el código siguiente:
[When("I click the \" (.*)\" link")]
public void WhenIClickALinkNamed(string linkName) {
var link = WebBrowser.Link(Find.ByText(linkName));
if (!link.Exists)
Assert.Fail(string.Format(
"Could not find {0} link on the page", linkName));
link.Click();
}
Ahora, cuando vuelva a ejecutar las pruebas, no porque WatiN no puede encontrar un vínculo con el texto “ crear nuevo cliente ” en la página. Con sólo agregar un vínculo con la que el texto a la página principal, se pasará el paso siguiente.
¿Un modelo de detección aún? SpecFlow anima a la misma metodología de la red-Green-Refactor que es una grapa de métodos de desarrollo de la primera prueba. La granularidad de cada paso de una función se comporta como blinders virtuales para la implementación, el fomento de implementar sólo la funcionalidad que necesita realizar ese paso pasar.
Pero, ¿qué ocurre con TDD dentro de BDD procesar? Sólo trabajo en el nivel de página en este momento, y aún tengo que implementar la funcionalidad que realmente se crea el registro del cliente. Por motivos de brevedad, let’s implementar el resto de los pasos ahora (consulte de figura 8).
La figura 8 de los pasos restantes en la definición de paso
[When(@"I enter the following information")]
public void WhenIEnterTheFollowingInformation(Table table) {
foreach (var tableRow in table.Rows) {
var field = WebBrowser.TextField(
Find.ByName(tableRow["Field"]));
if (!field.Exists)
Assert.Fail(string.Format(
"Could not find {0} field on the page", field));
field.TypeText(tableRow["Value"]);
}
}
[When("I click the \"(.*)\" button")]
public void WhenIClickAButtonWithValue(string buttonValue) {
var button = WebBrowser.Button(Find.ByValue(buttonValue));
if (!button.Exists)
Assert.Fail(string.Format(
"Could not find {0} button on the page", buttonValue));
button.Click();
}
[Then(@"I should see the following details on the screen:")]
public void ThenIShouldSeeTheFollowingDetailsOnTheScreen(
Table table) {
foreach (var tableRow in table.Rows) {
var value = tableRow["Value"];
Assert.IsTrue(WebBrowser.ContainsText(value),
string.Format(
"Could not find text {0} on the page", value));
}
}
Vuelva a ejecutar las pruebas y las cosas no ahora porque no hay una página para especificar información del cliente. Para permitir que los clientes que se cree, se necesita una página Crear vista de cliente. A fin de ofrecer esta vista en ASP.NET MVC, necesito un CustomersController que ofrece esa vista. Ahora necesito código nuevo, lo que significa que estoy paso a paso en el bucle externo de BDD y en el bucle interno de TDD, tal como se muestra en de figura 2.
El primer paso es crear una falta de prueba unitaria.
Escribir pruebas unitarias para los pasos de implementación
Después de crear una clase de prueba CustomerControllersTests en el proyecto UnitTest, tiene que crear un método de prueba que haga uso de la funcionalidad que se va a exponer en el CustomersController. En concreto, desea crear una nueva instancia de la controladora, llame a su método Create y asegurarse de que recibe la vista y el modelo correcto de devolución:
[TestMethod]
public void GetCreateShouldReturnCustomerView() {
var customersController = new CustomersController();
var result = customersController.Create() as ViewResult;
Assert.AreEqual("Create", result.ViewName);
Assert.IsInstanceOfType(
result.ViewData.Model, typeof(Customer));
}
Este código aún no compila porque no se hayan creado CustomersController o su método Create. Al crear ese controlador y un método de crear vacío, el código se compila y la prueba falla ahora, que es el siguiente paso que desee. Si completa el método Create, ahora se pasa la prueba:
public ActionResult Create() {
return View("Create", new Customer());
}
Si vuelve a ejecutar las pruebas de SpecFlow, obtendrá un poco más, pero aún no pasa la función. En este momento, la prueba se producirá un error porque no tiene una página de vistas de Create.aspx. Si agrega, junto con los campos adecuados según se indica mediante la función, moverá otro paso más cerca para una característica completada.
El proceso de exterior para implementar esta funcionalidad de creación se parece a esto de figura 9.
.jpg)
La figura 9 del proceso de prueba de escenario para unidades
Esos mismos pasos repetirán a sí mismos a menudo en este proceso, y la velocidad de recorrer en iteración los aumentará en gran medida con el tiempo, especialmente a medida que implemente los pasos de la aplicación auxiliar (haciendo clic en vínculos y botones, rellenando formularios y así sucesivamente) en el proyecto AcceptanceTests y anotar para probar la funcionalidad clave en cada escenario.
Desde un válido Crear vista, la función ahora rellenará los campos de forma adecuada y intentará enviar el formulario. Ahora se puede ver lo que ocurre a continuación: La prueba se producirá un error porque aún no tiene la lógica necesaria para guardar el registro del cliente.
Siguiendo el mismo proceso que antes, crear la prueba mediante el código de prueba de unidades que se muestra anteriormente en de figura 3. Después de agregar un método Create vacío que acepte un objeto de cliente para permitir que esta prueba compilar, observa se producirá un error, a continuación, completa, como el método Create para:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Customer customer) {
_repository.Create(customer);
return View("Details", customer);
}
El controlador es sólo un controlador y la creación real del registro del cliente pertenece a un objeto de depósito que tiene conocimientos de un mecanismo de almacenamiento de datos. He dejado que la aplicación fuera de este artículo para mayor brevedad, pero es importante destacar que, en un escenario real, la necesidad de un repositorio guardar a un cliente debe iniciar sub-loop otra de las pruebas unitarias. Cuando se necesita tener acceso a cualquier objeto de colaboración y el objeto todavía no existe o no ofrece la funcionalidad que necesita, debe seguir el mismo bucle de prueba de unidad que va a seguir para sus funciones y controladores.
Una vez que se ha implementado el método Create y tiene un repositorio de trabajo, debe crear la vista de detalles, que toma el nuevo registro de cliente y lo muestra en la página. A continuación, se puede ejecutar SpecFlow una vez más. Por último, después de muchos de los bucles de TDD y sub-loops, tiene ahora una característica de transferencia que pruebe algunas funcionalidades de extremo a extremo en su sistema.
¡ Enhorabuena! Ahora que ha implementado una unidad de funcionalidad de extremo a extremo con una prueba de aceptación y un conjunto completo de las pruebas unitarias que garantice la nueva funcionalidad continuará funcionando como el sistema se expande para agregar nuevas características.
Una palabra sobre la refactorización
Con suerte, cuando cree las pruebas de nivel de unidad en el proyecto UnitTests, está refactorización constantemente con la creación de cada prueba. Cuando se mueve hacia atrás por la cadena de pasar las pruebas unitarias a la aceptación de un paso de prueba, siga el mismo proceso, inspeccionando las oportunidades de refactorización y perfeccionar la implementación para cada característica y todas las características que van detrás.
Estar en el lookout oportunidades refactorizar el código del proyecto AcceptanceTests también. Puede encontrar que algunos pasos suelen repetirse con frecuencia a través de varias características, especialmente los pasos del dado. SpecFlow, puede mover fácilmente estos pasos en archivos de definición de paso independientes organizados por función, como, por ejemplo, LogInSteps.cs. Esto deja los archivos de definición de paso principales desde el principio y de destino en el único escenario que está especificando.
BDD trata el foco en el diseño y desarrollo. Al elevar su enfoque de un objeto a una función, permite que usted mismo y a su equipo desde la perspectiva del usuario de un sistema de diseño. Como característica de diseño se convierte en el diseño de la unidad, asegúrese de crear pruebas con la característica de la cuenta y asegúrese de que las pruebas se guiarán por pasos discretos o tareas.
Al igual que cualquier otra práctica o disciplina, BDD necesita tiempo para que quepa en el flujo de trabajo. Recomienda que pruebe usted mismo, utilice cualquiera de las herramientas disponibles y ver cómo funciona con el tiempo. Durante el desarrollo con este estilo, preste atención a las preguntas que BDD le anima a pedir. Constantemente pausar buscan formas de mejorar el proceso y la práctica y colaborar con otras personas en las ideas de mejora. Mi esperanza es que, sin importar el conjunto de herramientas, el estudio de BDD agrega valor y el enfoque a sus propias prácticas de desarrollo de software.
Brandon Satrom funciona como un departamento de formación de desarrolladores de Microsoft en Austin, Texas. Su blog en userinexperience.com de y se pueden encontrar en Twitter como @ BrandonSatrom .
Gracias a los siguientes expertos técnicos de refviewing en este artículo: Paul Rayner y Clark venta