¿Es esta experiencia típica de pruebas unitarias?

He escrito una clase de 220 líneas con 5 métodos públicos. Tengo una clase de prueba de unidad que ejecuta 28 pruebas en esta clase que ocupa más de 1200 líneas de código, pero esto se debe principalmente a código repetido utilizado en la configuración de las pruebas. Este código está probando el DAL en mi proyecto para garantizar que interactúe correctamente con la base de datos y que los procedimientos almacenados involucrados se estén ejecutando correctamente. Parece que he trabajado mucho para probar muy poco código. Estoy usando simulacros con los simulacros de Rhino para evitar escribir mis propios talones cuando sea posible.¿Es esta experiencia típica de pruebas unitarias?

¿Es esta la experiencia de prueba de unidad típica?

Fuente

2012-01-28 Peter Smith

¿por qué crees que la duplicación está bien en las pruebas? – flq

+1 para compensar el downvote. Stack Overflow está destinado a ayudar tanto a los programadores nuevos como a los experimentados, y creo que la mayoría de nosotros teníamos esta pregunta nosotros mismos en algún momento. –

La duplicación puede ser un efecto secundario de tratar de mantener las pruebas sin estado, algo que requiere un poco más de esfuerzo cuando se trata de una base de datos. Sin embargo, de todos modos, es mejor seguir SECO lo más cerca posible. – ose

Es bastante común que las clases de prueba de la unidad contienen más clases LOC que reales. Eso es razonable teniendo en cuenta la configuración de dependencias, la preparación de datos falsos y todo el alboroto relacionado con las pruebas de unidades.

Sin embargo, probar DAL en términos de interacción con la base de datos y comprobar si se invocan procedimientos correctos huele a una prueba de integración. Es posible que desee volver a pensar lo que quiere hacer. Con la prueba unitaria, todos los DB-talking deberían ser burlados/apagados.

Si tiene problemas con 1200 líneas de código, puede dividir sus pruebas en contextos, por ej. cada contexto corresponde a una parte particular de la clase probada (método público, conjunto de propiedades, etc.).

Editar:

sólo para añadir ejemplo que otros a hacer eso también. Puede consultar las fuentes de las clases Aggregate y AggregateTests del proyecto Edulinq.15 pruebas para probar 3 métodos públicos, con una clase de exámenes que es el doble de la probada.

Fuente

2012-01-28 23:34:38

Sí, esto es bastante normal para las pruebas unitarias.

El tamaño del código requerido para ejecutar las pruebas a menudo se subestima, en particular el código que requiere una gran cantidad de texto repetitivo de configuración, como el acceso a la base de datos.

Si bien puede tratar de refactorizar el código de configuración en métodos separados, esto es bastante normal para la situación que está describiendo.

Con 28 pruebas, sus 1200 líneas se reducen a aproximadamente 43 por prueba. Teniendo en cuenta que está repitiendo su código de configuración, esto es bastante razonable.

Fuente

2012-01-28 23:31:07 ose

Como comentó flq, es una buena idea mover un código común a otro método. Reduce la posibilidad de errores de copiado y pegado, le permite escribir nuevas pruebas más rápido y evita que el texto repetitivo oculte el objetivo principal de cada prueba. –

Otra cosa: las líneas de código se consideran una medida bastante pobre de "tamaño". Esta pregunta probablemente no merezca el tiempo y el esfuerzo para usar métricas más sofisticadas, pero de todos modos no te preocupes demasiado por LOC. – ose

28 pruebas para una clase suena como que la clase está haciendo demasiadas cosas.

Fuente

2012-01-28 23:31:38 Maggie

Aunque estoy de acuerdo, hay situaciones en las que se podrían requerir muchas pruebas. Aunque eso se puede reducir utilizando la nueva función 'Caso de prueba' en nunit –

No estoy de acuerdo. Las buenas pruebas unitarias son minúsculas; cada uno verifica un aspecto específico y puede que no cubra un método completo. Por ejemplo, si estuviera probando un método "setUserName", tendría pruebas separadas para la entrada nula, la entrada vacía, la entrada de larga duración, la entrada con caracteres inválidos y la entrada válida ... cada uno con el nombre adecuado para que yo sepa exactamente qué salió mal si uno se desmayó. ¡Son 5 pruebas para un método, solo para principiantes! –

¿De qué manera es típico?

Si quiere decir que tiene más código de prueba unitaria que el código real, entonces sí. Pero debe tratar el código de prueba de la unidad de la misma manera que su código "real", ya que debe eliminar la duplicación y refactorizarla hasta que sea lo más delgada posible/deseable.

Además, si está probando el DAL y la interacción con una base de datos real, entonces lo que tiene allí es una prueba de integración.

EDITAR

que he tomado recientemente para las clases base de pruebas unidad de escritura para los patrones comunes de ensayo, que tienen una gran cantidad de código de configuración y métodos de ayuda en ese país. Mi clase base de prueba unitaria más reciente es genérica y me permite probar las clases de wcf-web-api con mucha facilidad. Por lo tanto, mis clases de prueba reales son muy delgadas y 'al punto'. YMMV

Fuente

2012-01-28 23:32:44

Bien señaló la prueba de integración. – ose

Es posible que desee intentar escribir algunas pruebas que se ejecutan directamente en la base de datos y considerar si eso es mejor. Me parece más trabajo conseguir la configuración de la base de datos, pero menos trabajo ya que no necesito falsificar las capas inferiores. Las pruebas son más lentas, pero verifican las cosas más completamente. Por supuesto, no es realmente una prueba de unidad en este punto.

Fuente

2012-01-28 23:56:44

¿Es esta experiencia típica de pruebas unitarias?

Respuesta

Cuestiones relacionadas