MVC - Unidad probando las cosas incorrectas?

Question

Mientras practicaba algo de TDD en el trabajo para un proyecto ASP.Net MVC, encontré una serie de escenarios en los que estaba escribiendo pruebas para asegurar que determinadas acciones devolvían las vistas correctas o tenían atributos particulares en ellas ([ChildActionOnly], etc.). (De hecho, encontré una cantidad de publicaciones interesantes aquí SO sobre métodos de extensión útiles para ayudar a lograr esto).

Cuando tuve mi primer contacto con los conceptos de la unidad de pruebas y TDD cuando en un curso hace unos años, el énfasis se basa en gran medida de que las pruebas deberían concentrarse en circuito de comprobación detrás de las características deseado por el usuario y la funcionalidad - los 'requisitos' del proyecto central si se quiere.

Mi pregunta es: si este es el caso, ¿las pruebas de nivel inferior están buscando el archivo de vista correcto, o una acción con un atributo particular, etc. que realmente no abarca de qué se trata la metodología de pruebas unitarias? ¿Estoy escribiendo pruebas por las razones equivocadas (es decir, simplemente para protegerme a mí mismo y a otros colegas de cometer un error de refactorización) o son estos casos válidos de valiosas pruebas unitarias?

Answer 1

Si un método de controlador puede devolver una de dos (o más) vistas dependiendo de alguna lógica, entonces sería útil una prueba de unidad que afirmara la vista correcta. Lo mismo ocurre con un método de controlador que inserta atributos particulares según la lógica.

estoy escribiendo pruebas por las razones equivocadas (es decir, la simple protección de otros colegas de cometer un error refactorización) o son estos casos válidos de pruebas de unidad de valor?

La captura de errores de regresión es uno de los beneficios de las pruebas unitarias, especialmente útil cuando se refactoriza. Si accidentalmente cambió la vista devuelta mientras realizaba una refactorización que sería muy útil para detectar antes, en lugar de esperar una prueba que solo se ejecutó cuando la aplicación se estaba ejecutando.

Answer 2

Si su acción devuelve diferentes vistas (o resultados de acción) dependiendo de alguna lógica. Escribe una prueba.

Si siempre devuelve Vista(), entonces no.

Si devuelve una vista con un nombre diferente al nombre de su acción, entonces podría argumentar que sería una buena idea escribir una prueba.

Answer 3

Depende. Para usar uno de sus ejemplos: Verificar si una acción tiene un atributo particular está bien, pero es mejor escribir una prueba que verifica que un comportamiento está funcionando como se esperaba, que fallaría si el atributo faltara.

Dicho esto, en última instancia, sus pruebas son una red de seguridad. Si tiene una posibilidad razonable de evitar que un error se filtre en algún momento en el futuro, está haciendo su trabajo.

Si es una prueba simple que tiene poca sobrecarga y pocas posibilidades de romperse arbitrariamente en el futuro, adelante. Prefiero tener demasiadas pruebas que muy pocas.

Answer 4

De hecho, sus pruebas deberían probar su lógica. Eso no debería desaparecer. Sin embargo, idealmente debe escribir pruebas para cualquier cosa que pueda salir mal. Por ejemplo, asegurar que todos los métodos que necesitan seguridad tengan un atributo Autorizar adecuado. Esta es una prueba de seguridad.

Definitivamente, usted decide qué es útil para probar.