Pruebas de rendimiento Versus Unidad de Pruebas

Question

estoy leyendo de Osherove "El arte de la Unidad de Pruebas", y aunque aún no lo he visto decir nada acerca de las pruebas de rendimiento, dos pensamientos todavía me ocurrió:

• Rendimiento las pruebas generalmente no pueden ser pruebas unitarias, porque las pruebas de rendimiento generalmente necesitan ejecutarse durante largos períodos de tiempo.
• Las pruebas de rendimiento en general no pueden ser pruebas de unidad, debido a problemas de rendimiento demasiado a menudo se manifiestan en un nivel de integración o sistema (o al menos la lógica de una sola unidad de prueba necesaria para recrear el rendimiento del entorno de integración serían demasiado involucrado para ser una prueba unitaria).

Particularmente por el primer motivo mencionado anteriormente, dudo que tenga sentido que las pruebas de rendimiento sean manejadas por un marco de pruebas unitarias (como NUnit).

Mi pregunta es: ¿mis hallazgos/tendencias se corresponden con los pensamientos de la comunidad?

Answer 1

Acepto sus conclusiones/aprendizajes. Las verdaderas pruebas unitarias solo prueban una parte del sistema, ignorando, burlándose o fingiendo el resto según sea necesario. Las pruebas de integración (o las pruebas de regresión) prueban que la mayoría o todas las unidades trabajen juntas, y esa es la verdadera medida del rendimiento.

Answer 2

Las pruebas de rendimiento pueden estar compuestas por pruebas unitarias.

Por ejemplo, una prueba unitaria puede arrojar varios parámetros diferentes en un método y verificar que el método arroje un resultado esperado. Una prueba de rendimiento puede ejecutar esa prueba unitaria 1000 veces (o cualquier valor que tenga sentido para usted) mientras graba todo, desde la CPU y los contadores de memoria hasta el tiempo que tomó cada prueba.

Answer 3

En algunas situaciones, puede usar pruebas unitarias para asegurarse de que una operación finalice dentro de un cierto período de tiempo. Si desea agregar más funciones a su operación, pero no desea sacrificar el rendimiento, puede usar pruebas unitarias para afirmar eso. Por supuesto, este tipo de pruebas unitarias dependen de la máquina, pero puede agregar algunas variables o configuraciones adicionales a la ecuación.

Answer 4

Todo depende de lo que usted llame pruebas de rendimiento. Cuando se optimiza un código específico, suelo usar algo muy similar a la prueba unitaria (¿debería llamarlo prueba de rendimiento de la unidad?). Eso es básicamente lo que hago en este question (aunque no me importa usar realmente un marco de prueba de unidad). Pero también hago este tipo de cosas para optimizar mi código de producción C++ dentro del marco de prueba de la unidad BOOST.

Realmente hay muchos tipos de pruebas de rendimiento en los diferentes niveles y con diferentes propósitos (las pruebas de resistencia de carga pesada, perfilado, micro optimización). Las pruebas de rendimiento de las que está hablando en su pregunta parecen estar en el nivel de prueba funcional. Un nivel para el cual probablemente no usará el marco de pruebas de unidades de todos modos.

Answer 5

Las pruebas unitarias no deberían tardar en ejecutarse porque solo está probando una unidad/sistema muy específico. Al igual que si su sistema bajo prueba es claseA: IClassA, usted hace su burla/tropezar y sólo probar el comportamiento de claseA, y no debe ser comprobación de comportamientos que no sea claseA, como si claseA utiliza ClassB. Debería inyectar un simulacro de ClassB en lugar del concreto para lograr esto.

En términos de pruebas de rendimiento, tiene sentido seguir utilizando un marco de prueba como NUnit/MBUnit/MavenThought, simplemente mantenga estas pruebas en un ensamblaje separado y no las invoque como parte de las pruebas de su unidad.

tanto, si utiliza Rastrillo para invocar sus pruebas, algunas de sus tareas podría ser:

Rake Test:All   #Run all unit tests 
Rake Test:Acceptance #Run all acceptance tests 
Rake Test:Performance #Run all performance tests 
Rake Test:Integration #Run all integration tests 

Luego, con su integración continua, prueba: Todo, siempre se invoca después de una construcción exitosa, donde como prueba : El rendimiento se invoca a las 12 a.m. una vez al día.

Answer 6

Acepto que las pruebas de rendimiento no pueden ser pruebas unitarias, pero no hay ninguna razón por la que no podamos tener otro conjunto de pruebas llamadas pruebas de rendimiento. En términos generales las pruebas se dividen en dos categorías

a) Las pruebas unitarias

b) Integración Pruebas de

Llevamos a cabo pruebas de integración de nuevo la base de datos real (en lugar de en la memoria) para asegurar las secuencias de comandos SQL, la hibernación los repositorios funcionan como se esperaba

Mi idea es que podemos agregar otro conjunto de pruebas llamadas pruebas de rendimiento que forman parte de la compilación nocturna que prueba el rendimiento de ciertas funciones. Esto es importante para rastrear las estadísticas después de un re factoring de código o para evaluar si los cambios en una parte de la aplicación pueden tener consecuencias no deseadas en otra.

Me he encontrado con JunitPerf que podría ayudarme a lograr este objetivo.

Answer 7

Recuerdo que hace años Microsoft abogó por que los programadores realicen pruebas de rendimiento de sus asp individuales mediante el uso de Visual Studio Net Application Center Test (ACT). Existía (todavía puede estar ahí) una metodología completa para realizar un Análisis de Costos de Transacción (TCA) en asp individuales. Dicho esto, estas asps podrían probarse usando un controlador web y posibles objetos simulados para aislar el código bajo prueba (es decir, imitar el acceso a DB si no se desarrolló).

Este enfoque se puede seguir con cualquier prueba de unidad siempre que tenga un controlador y, opcionalmente, un marco de objeto simulado para encargarse de las dependencias que aún no están escritas. Este enfoque también se hizo popular con SOAPUI \ LOADUI. Además, recomendaría aislar declaraciones SQL individuales que puedan ser probadas (optimizadas) contra un diseño de base de datos dado. Esta prueba de rendimiento de la unidad SQL (DB) se puede realizar al principio del SDLC y descubrirá oportunidades de optimización de consultas.

en términos de costo y valor: yo he encontrado pruebas de rendimiento UNIDAD temprano, usando Mock objetos en su caso, identificará pérdidas de memoria y uso excesivo de CPU y S de disco a principios de la SDLC pero me gustaría 'selección de la cereza' el código bajo pruebas para artículos de mayor riesgo

Answer 8

Existen diferencias de contraste entre la prueba de la unidad y la prueba de rendimiento. En primer lugar, la prueba unitaria es probar la aplicación contra sus requisitos funcionales. por ejemplo, si desea asegurarse de hacer clic en la pestaña Inicio, la página web se desplaza a su hogar, mientras que la prueba de rendimiento es un tipo de prueba no funcional. Aquí le preocupa la estabilidad y la capacidad de respuesta de la aplicación bajo una carga de usuario determinada durante cierto tiempo.