javascript - example - Pruebas unitarias karma-runner/jasmine profiling

pruebas unitarias angular 6

Question

Para las pruebas unitarias usamos grunt / karma-runner / jasmine / phantom.js. Debido a que intentamos cubrir cualquier funcionalidad nueva, varias pruebas unitarias crecen rápidamente. Y, desafortunadamente, el tiempo para las pruebas también aumenta. Ahora no es crítico y toma 10 segundos para 1000 pruebas, pero va peor y peor.

Y preguntas:

1. Lo sé, algunas de las pruebas están mal escritas (mucho tiempo), pero ¿cuál debería optimizar? ¿Existe algún perfilador de karma / jazmín que mida el tiempo de ejecución de cada prueba?

2. ¿Puedo iniciar más procesos / subprocesos de karma-runner , porque la CPU se usa solo para 5% -10%? Pruebas unitarias realmente independientes.

3. Cada vez que guardo un archivo, karma: watch inicia todas las pruebas, puede existir alguna opción para karma-runner , que reinicia solo las pruebas de la carpeta actual (usamos la regla: la unidad prueba el archivo.spec.js almacenado en la misma carpeta como fuente file.js)?

Gracias,

update1: ¿Alguien me sugiere usar iit / ddescribe para jasmine (lo mismo que .only para mocha) y es una gran opción para desarrollar / depurar, pero puede existir de otra manera?

Publico la pregunta en el foro de usuarios de karma here .

Answer 1

1a) Sobre la creación de perfiles: puede usar los reporteros de karma , agregue a su karma-config estas cadenas:

 reporters: [
''progress'',
''junit'',
],
junitReporter: {
outputFile: basePath + ''test_out/unit.xml'',
suite: ''unit''
},

producirá bonito xml como este:

<testcase name="BuilderController should have a tileSelectorId" time="0.015" classname="unit Chrome 31.0.1650 (Windows 7).tileBuilder testing"/>
<testcase name="BuilderController by default should sort by title" time="0" classname="unit Chrome 31.0.1650 (Windows 7).tileBuilder testing"/>

Y puede ordenar y elegir qué prueba más lenta debe optimizarse

1b) También puedes usar reportSlowerThan desde karma config

 reportSlowerThan: 100,

Karma te informará sobre pruebas de más de 100 ms.

2) No sé cómo iniciar más procesos / subprocesos de karma-runner.

3) porque grunt: vea que ha cambiado el nombre de archivo.js, puede iniciar el nombre de archivo correspondiente.spec.js, por lo que tiene que escribir una tarea especial grunt

y use ddescribe e iit para comenzar, solo especifique / lo describa.

Answer 2

Si está buscando una manera de saber qué especificaciones son lentas, escribí una entrada de blog ( http://jipiboily.com/how-to-know-jasmine-specs-are-slow/ ) al respecto, pero la versión corta es uso este reportero que hice:

// This works under Jasmine 2.3
var slowSpecsReporter = {
specStarted: function(result) {
this.specStartTime = Date.now()
},
specDone: function(result) {
var seconds = (Date.now() - this.specStartTime) / 1000
if (seconds > 0.5) {
console.log(''WARNING - This spec took '' + seconds + '' seconds: "'' + result.fullName + ''"'')
}
},
}
jasmine.getEnv().addReporter(slowSpecsReporter);

Answer 3

Encontrar pruebas lentas

• reportSlowerThan (los puntos o el informador de progreso informarán todas las pruebas que son más lentas que el número dado en ms),

• puedes saltar al navegador y hacer un perfil de tus pruebas de la misma manera que lo harías con una aplicación (por ejemplo, los flamecharts en Chrome son impresionantes).

Haciendo las pruebas más rápidas

• paralelización:

  Estamos trabajando en esto. Podrá paralelizar las pruebas en varios navegadores. Por supuesto, estos navegadores no tienen que ejecutarse en la misma máquina, por lo que también podrá usar varias máquinas.

  No creo que ejecutar varias instancias de Karma en sí ayude mucho, ya que está escrito de una manera muy "no bloqueante" y no he visto que sea el cuello de botella. Sin embargo, debemos optimizar el uso de la CPU / memoria. Muchas mejoras en esta área están llegando en v0.12.

• ejecutando solo un subconjunto de pruebas:

  Deberías usar totalmente iit / ddescribe (Jasmine). ¿Alguna razón por la que esto no te funciona? Por cierto La implementación de Mocha de it.only() y describe.only() tiene problemas, por lo que recomiendo Jasmine (o corrección de Mocha).

  También hay un prototipo del plugin Google Closure que solo carga los archivos que realmente necesita (digamos que iit una prueba, solo cargará / analizará / evaluará los archivos que realmente necesita para esa iit ). Esto mejora significativamente el tiempo de inicio en grandes proyectos; deberíamos hacer trucos similares para otros cargadores de módulos (RequireJS, CommonJS).

• escribir código más rápido:

  Probablemente ya lo sepas ... ;-)

  DOM es lento. Una buena separación de lógica / DOM te permitirá probar más cosas sin tocar realmente DOM. Si utiliza Angular, puede consultar el ejemplo de las directivas de prueba .

  El uso del patrón de inyección de dependencia ayuda mucho, ya que básicamente minimiza el entorno que necesita para preparar (y también derribar) para cada prueba. Aquí hay un ejemplo .

  En general, las pruebas más bajas son más rápidas. Creo que es bueno cubrir cada funcionalidad / problema con la prueba más baja posible.

• eliminar las fugas de memoria:

  Si las pruebas pierden memoria, el navegador se volverá más lento y más lento, por lo que el número de prueba 1000 será bastante lento aunque esté bien escrito. Asegúrese de que cada prueba libere todas las referencias. Puede usar http://localhost:9876/debug.html y http://localhost:9876/debug.html perfil de la memoria. Verifique la memoria antes de ejecutar (después de que Jasmine ejecutó todos los bloques de describe() y recopiló las pruebas) y luego, después de ejecutar las pruebas, debería ser la misma.

  Encontrar algunas fugas de memoria es más difícil que otras, pero puede mejorar significativamente la velocidad. He visto cosas como de ~ 5 minutos a menos de un minuto con solo eliminar las fugas de memoria.