He estado leyendo acerca de MVC en el que los autores sugieren que la capacidad de prueba es uno de los principales puntos fuertes de MVC. Van a compararlo con ASP.NET WebForms y lo difícil que es probar el código en WebForms.Pruebas unitarias Código ASP.NET detrás de
Entiendo que es difícil, pero ¿alguien puede explicar cómo se escribieron las pruebas unitarias para probar el código detrás de la lógica en los viejos tiempos?
El código detrás métodos son lisos en una clase (la única diferencia con otra clase es que esta clase hereda del objeto de página)
Por lo tanto, es comprobable. la mayoría de los problemas surgen porque los métodos estaban estrechamente relacionados con los controles web.ui como la grilla; no eran tan fáciles de falsificar. Si no falsificó los controles de la interfaz de usuario, también estaba probando el funcionamiento interno de los controles de la interfaz de usuario, que es un poco exagerado.
En los viejos tiempos probé formularios web aspnet utilizando el modelo Model View Presenter. Pude probar el código con este patrón porque resumí la lógica condicional/loops/etc en una clase separada que no vivía dentro del framework de webforms.
Lo que quedaba en las webforms codebehind no era más que unas pocas propiedades y una llamada en la carga de la página para iniciar la clase del presentador.
Luego, cada controlador de eventos simplemente pasaría el trabajo a la clase del presentador.
Pasé una gran cantidad de tiempo con este patrón y encontré que hace que las cosas sean mucho más amigables con las pruebas, pero es una gran cantidad de trabajo en comparación con aspnet mvc