ACTUALIZAR. Aquí hay un paquete simple que he creado para agregar una configuración mínima de Karma a cualquier proyecto con un solo comando npm install min-karma.
Me gustaría aclarar algunos posibles conceptos erróneos sobre el karma y el transportador . Preguntas Karma refiere realmente a Adaptador para angular del Escenario Runner , que, sin embargo, parece estar abandonado, con el transportador está recomendando en su lugar.
Karma
Karma es un corredor de pruebas que ejecutará los archivos JavaScript especificados en su archivo de configuración de forma explícita o mediante el uso de node-globs . (Para las plantillas externas que no son de JavaScript , la Guía de pruebas unitarias de Angular recomienda usar el preprocesador html de Karma para compilarlas primero en JavaScript).
Estos pueden ser todos sus archivos de origen, algunos de ellos, algunos de ellos más algunos archivos adicionales o archivos irrelevantes para su proyecto, solo proporcionan una configuración adicional, ¡lo que sea! Puede tener varios archivos de configuración de karma para diferentes propósitos, que puede ejecutar en paralelo o uno por uno. Cada proceso de karma lanza su propio conjunto de navegadores (actualmente están disponibles) .
Esta característica de Karma para ejecutar solo un conjunto de archivos es lo que lo hace perfecto para pruebas rápidas que se ejecutan en segundo plano en cada edición de archivo fuente, y obtener comentarios inmediatos, ¡lo cual es genial! El único aspecto negativo es el informe de errores "ruidosos" que, con suerte, mejorará.
El karma no es solo para pruebas unitarias
La prueba unitaria es para una sola unidad de su código fuente. En el caso de Angular, una unidad típica es Componente angular ( Service, Factory, Provider, Controller, Filter, Directiveetc.). Recuerde mantener sus Controllers, por lo que demasiadas pruebas unitarias delgadas de estos últimos es una señal de alerta .
En una prueba unitaria , todas las demás unidades de código de las que depende esta unidad (las denominadas dependencias de la unidad) no deben probarse al mismo tiempo. En su lugar, deberían ser "burlados", por ejemplo, reemplazados por algo simple como instancias ficticias. Angular proporciona un excelente soporte de entorno simulado . Idealmente, desea ver todas esas simulaciones directamente dentro de sus pruebas, por lo que nunca tendrá que preguntarse de dónde provienen todas esas dependencias.
Karma es igualmente útil para las pruebas de integración , donde un grupo de unidades de código fuente se prueba juntas, y solo se burlan algunas de sus dependencias . Es importante recordar que cualquier dependencia se proporciona de forma predeterminada desde sus módulos de código fuente (siempre que esos módulos se inyecten directamente en sus pruebas o sean dependencias de otros módulos inyectados (en cuyo caso no es necesario inyectarlos) , pero no hay ningún daño en hacerlo). Las dependencias simuladas anularán las proporcionadas.
Correr rápido y con frecuencia es la característica principal de Karma . Esto significa que desea evitar cualquier solicitud del servidor, cualquier consulta a la base de datos, cualquier cosa que pueda tomar más de fracciones de segundos. (¡ De lo contrario NO será rápido! ) Esos procesos largos son los que desea burlarse . Esto también explica por qué es una mala práctica colocar servicios sin procesar de bajo nivel $httpdirectamente dentro de sus controladores o cualquier unidad lógica de negocios complicada. Al agrupar esos servicios de comunicación externos de bajo nivel en servicios dedicados más pequeños, hace que sea mucho más fácil "burlarse de ellos".
Lo que Karma no hace es ejecutar su sitio como está, que es lo que son las pruebas de extremo a extremo (E2E). En principio, podría utilizar los métodos internos de Angular para recrear el sitio o sus piezas. Lo cual, para piezas pequeñas, puede ser útil y una forma rápida, por ejemplo, de probar directivas.
Sin embargo, no es una forma recomendada de introducir código complicado dentro de sus pruebas. Cuanto más lo haga, más posibilidades tendrá de cometer errores en ese código en lugar de lo que está probando.
Es por eso que personalmente no me gusta la forma complicada mencionada a menudo de probar métodos que utilizan métodos de bajo nivel como $http. Funciona de forma más limpia para aislar cualquier referencia a métodos de bajo nivel en métodos dedicados propios, cuya única responsabilidad es realizar solicitudes http. Estos métodos dedicados deberían poder funcionar con un backend real , ¡no con uno falso! Que puede probar fácilmente, de forma manual o incluso perfectamente bien con Karma ejecutándose con otra configuración especial , siempre que no mezcle esa configuración con la que generalmente se usa para ejecutar Karmaregular y rápido. Ahora, después de haber probado sus pequeños servicios dedicados, puede burlarse de ellos de manera segura y fácil para probar su otra lógica y poner estas pruebas en su configuración habitual de Karma .
Para resumir. Utilice Karma para ejecutar cualquier conjunto de archivos JavaScript. Es (debería ser) rápido. No ve su aplicación completa, por lo que no puede probar el resultado final de manera efectiva y confiable. ¿Lo ejecutaría con transportador ? ¿Por qué habría? Ejecutar Transportador ralentizaría mis pruebas, anulando el propósito de Karma . Es fácil ejecutar Transportador por separado.
Transportador
Transportador es:
un marco de prueba de un extremo a otro para aplicaciones AngularJS. Transportador ejecuta pruebas contra su aplicación que se ejecuta en un navegador real, interactuando con ella como lo haría un usuario.
Entonces Protractor hace exactamente lo que Karma no hace: ejecuta tu aplicación final real. Esto revela tanto su poder como sus limitaciones:
La ejecución de la aplicación completa es la única prueba final confiable de que su aplicación funciona como se esperaba. ¡Puede escribir escenarios completos de historias de usuario y ponerlos en sus pruebas!
Pero es más difícil rastrear errores sin aislar unidades individuales de su código fuente. Es por eso que todavía necesitas Karma para probar tu código JavaScript primero.
¿Ahora querría ejecutar Transportador con Karma ? Seguramente puedo ejecutarlos en ventanas de terminal separadas, en paralelo. En principio, podría hacer que compartan archivos de prueba si es necesario, pero normalmente prefiero no hacerlo. ¿Por qué? Porque quiero que mis pruebas sean pequeñas con un único propósito específico.
La única excepción sería un archivo que defina macros de prueba útiles para ambos corredores. Sin embargo, esto no sería un archivo de prueba sino un archivo de definición de macros .
Aparte de eso, me gusta una clara separación entre mis pruebas. Los que se ejecutarán con frecuencia y rapidez, y los de la aplicación completa. Eso hace una clara separación entre cuando se usa Karma y cuando se usa Transportador .