Cómo hacer pruebas de unidad "basadas en el rendimiento" (punto de referencia) en Python

Question

Digamos que tengo mi código base para un nivel de cobertura de prueba unitario tan alto como tenga sentido. (Más allá de cierto punto, aumentar la cobertura no tiene un buen retorno de la inversión.)

Siguiente Quiero probar el rendimiento. Para comparar el código para asegurarse de que los nuevos commits no ralenticen las cosas innecesariamente. Estaba muy intrigado por zero tolerance policy de Safari para ralentizaciones de commits. No estoy seguro de si el nivel de compromiso con la velocidad tiene un buen retorno de la inversión para la mayoría de los proyectos, pero al menos me gustaría que me avisen que ha ocurrido una regresión de velocidad y poder emitir un juicio al respecto.

El entorno es Python en Linux, y una sugerencia que también era factible para los scripts de BASH me haría muy feliz. (Pero Python es el foco principal)

Answer 1

Si es posible, querrá realizar pruebas de rendimiento a nivel del sistema: pruebe su aplicación como un todo, en contexto, con datos y comportamientos lo más cercanos posible al uso de producción.

Esto no es fácil, y será aún más difícil automatizarlo y obtener resultados consistentes.

Además, no puede usar una VM para las pruebas de rendimiento (a menos que su entorno de producción se ejecute en máquinas virtuales, e incluso entonces, tendría que ejecutar la máquina virtual en un host sin nada más).

Cuando dice realizar pruebas de rendimiento de la unidad, eso puede ser valioso, pero solo si se usa para diagnosticar un problema que realmente existe a nivel de sistema (no solo en la cabeza del desarrollador).

Además, el rendimiento de las unidades en las pruebas unitarias a veces no refleja su rendimiento en contexto, por lo que puede no ser útil en absoluto.

Answer 2

MarkR tiene razón ... hacer pruebas de rendimiento en el mundo real es la clave, y puede ser algo dudoso en las pruebas unitarias. Habiendo dicho eso, eche un vistazo al módulo cProfile en la biblioteca estándar. Por lo menos, será útil para darle un sentido relativo de commit-to-commit de cuán rápido se están ejecutando las cosas, y puede ejecutarlo en una prueba unitaria, aunque, por supuesto, obtendrá resultados en los detalles que incluyen los gastos generales. del propio marco de prueba de la unidad.

En total, sin embargo, si su objetivo es la tolerancia cero, necesitará algo mucho más robusto que esto ... cProfile en una prueba de unidad no lo cortará en absoluto, y puede ser engañoso.

Answer 3

Cuando realizo las pruebas de rendimiento, generalmente tengo un conjunto de prueba de entradas de datos, y mido cuánto tiempo le lleva al programa procesar cada una.

Puede registrar el rendimiento de manera diaria o semanal, pero no me parece particularmente útil preocuparme por el rendimiento hasta que se implemente toda la funcionalidad.

Si el rendimiento es demasiado pobre, exploto cProfile, lo ejecuto con las mismas entradas de datos y trato de ver dónde están los cuellos de botella.

Answer 4

Aunque estoy de acuerdo en que el rendimiento de las pruebas a nivel de sistema es en última instancia más relevante, si desea realizar pruebas de carga de estilo UnitTest para Python, FunkLoad http://funkload.nuxeo.org/ hace exactamente eso.

Las microcomponentes tienen su lugar cuando intentas acelerar una acción específica en tu código base. Y obtener pruebas de unidades de rendimiento subsiguientes es una forma útil de garantizar que esta acción que acaba de optimizar no retroceda involuntariamente en el rendimiento en futuras confirmaciones.