Cómo implementar TDD en ASP.NET WebForms

Question

Sé que la razón por la que Microsoft salió con ASP.NET MVC fue para simplificar el diseño basado en pruebas (TDD) para ASP.NET. Sin embargo, tengo una aplicación de campo marrón bastante grande (existente) en ASP.NET WebForms en la que me encantaría implementar algunas funciones de tipo TDD. Estoy asumiendo que HAY una forma de hacerlo, pero ¿cuáles son algunas opciones viables?

Answer 1

Microsoft presentó ASP.NET MVC porque pensaban que podían ganar dinero con un mercado sin explotar: aquellos que sienten que los formularios web son demasiado "pesados" y que están programando con un marco más liviano. Esto incluye a aquellos que están acostumbrados al paradigma de MVC.

También incluye a aquellos que no pudieron resolver cómo hacer pruebas unitarias en formularios web, y que desean usar pruebas unitarias y TDD.

La forma de hacerlo con formularios web, como con cualquier otra cosa, es separar todo menos el código de UI en clases separadas en una biblioteca de clases. Use TDD para desarrollar esas clases.

La siguiente capa de controversia es si es necesario usar TDD para desarrollar el resto del código: el marcado, el código del lado del cliente, las interacciones del usuario, etc. Mi respuesta es que si tiene el resto aislado y probado, que no vale la pena usar TDD para esto.

Considere: sus páginas deben tener un aspecto particular. ¿Vas a escribir una prueba de unidad fallida para demostrar que estás usando CSS correctamente? ¿Para demostrar que estás usando los estilos CSS correctos? No lo creo.

---

Para aclarar: en TDD, comenzamos con una prueba de unidad defectuosa. Luego hacemos los cambios más simples posibles que harán que la prueba tenga éxito.

Imagine el uso de TDD para una página web. ¿Qué pruebas fallidas va a producir?

1. de prueba está bien formado que la página HTML
2. Prueba de que la página incluye el título correcto
3. Prueba de que la página incluye
   1. "Enter ID" etiqueta
   2. Un cuadro de texto ID
   3. Una cuadrícula de datos
   4. Un botón "Ir"
4. Compruebe que la cuadrícula de datos esté vacía después de un GET
5. Pruebe que la cuadrícula se carga con datos del cliente 1 cuando se ingresa "1" en el cuadro de texto y se hace clic en "Ir".

Y ninguno de los anteriores prueba la apariencia de la página. Nada de esto prueba el comportamiento del lado del cliente de ningún JavaScript en la página.

Creo que es una tontería. En su lugar, pruebe su método DAL que recupera datos basados ​​en la ID. Asegúrese de que devuelve la ID correcta para la identificación 1.Entonces, ¿cuánto tiempo llevará probar manualmente la página para asegurarse de que se ve correcta, puede ingresar el "1" y hacer clic en "Ir", y que los datos que aparecen en la cuadrícula son los datos correctos para el cliente 1?

Test-Driven El desarrollo y las pruebas unitarias automatizadas están destinadas a probar el comportamiento. La interfaz de usuario de un formulario web es en su mayoría declarativa. Aquí hay un gran "desajuste de impedancia".

Answer 2

Puede ejecutar pruebas basadas en HTTP para probar la funcionalidad de alto nivel. Lo mejor sería encapsular el código de código subyacente en su capa de negocio y ejecutar pruebas unitarias en él.

Answer 3

Puede utilizar el marco oficial unittest: http://msdn.microsoft.com/en-us/library/ms182526.aspx

Answer 4

En primer lugar, es realmente difícil de probar Web Forms. Pero si divide la lógica en Controladores/Presentadores como el patrón MVC/MVP, al menos puede probar a los presentadores.

Pseudocódigo

Default.aspx

public void Page_Init(object sender, EventArgs e) { 
_presenter = new DefaultPresenter(IDependencyOne, IDependencyTwo etc) //Init new presenter, either from IoC container of choose or "new-it-up" 
} 

public void Save() { 
_presenter.Save(txtValue.Text) 
} 

de lo que puede probar fácilmente el presentador de manera aislada al menos =)