ACTUALIZACIÓN. 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 Karma y Transportador. Karma FAQ en realidad se refiere a Adaptador para el Scenario Runner de Angular, que, sin embargo, parece ser abandonado, con Transportador siendo recomendado en su lugar.

Karma

Karma es un ejecutor de pruebas que ejecutará los archivos JavaScript especificados en su archivo de configuración explícitamente o utilizando node-globs . (Para plantillas externas que no sean JavaScript , La Guía de Pruebas Unitarias de Angular recomienda usar Karma html preprocesador para compilarlos en JavaScript primero.)

Estos pueden ser todos sus archivos fuente, algunos de ellos, algunos de ellos más algunos archivos o archivos adicionales irrelevante para su proyecto, solo proporciona alguna 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 karma lanza su propio conjunto de navegadores (estos están actualmente 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 retroalimentación inmediata, que es brillante! El único negativo es el informe de error" ruidoso " que con suerte mejorará!

El karma no es solo para pruebas unitarias

Unit test es para una sola unidad de su código fuente. En el caso de Angular, una unidad típica es Angular Component (Service, Factory, Provider, Controller, Filter, Directive etc). Recuerde mantener su Controllers delgada, por lo que demasiadas pruebas unitarias para estos últimos es una bandera roja.

En una prueba unitaria , todas las demás unidades de código, en las que esta unidad depends (las llamadas 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 gran soporte para entornos simulados. Lo ideal es que quieras ver todas esas burlas directamente dentro de tus pruebas, por lo que nunca tendrás que preguntarte de dónde vienen todas esas dependencias.

Karma es igual de útil para Pruebas de Integración, donde grupo de código fuente unidades es probados juntos, con solo algunas de sus dependencias siendo burladas. Es importante recordar que cualquier dependencia se proporciona por defecto desde sus módulos de código fuente (siempre y cuando 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 daño para hacerlo). Las dependencias burladas anularán las proporcionadas.

Correr rápido y Frecuente es el principal característica de Karma . Esto significa que desea evitar cualquier solicitud de servidor, cualquier consulta de base de datos, cualquier cosa que pueda tardar más de fracciones de segundos. ( De lo contrario no será rápido!) Esos procesos largos son los que quieres simular. Esto también explica por qué es una mala práctica poner servicios raw de bajo nivel como $http directamente dentro de sus controladores o cualquier unidad de lógica de negocio complicada. Envolviendo esos servicios de comunicaciones exteriores de bajo nivel en servicios dedicados más pequeños, usted hace que sea mucho más fácil "burlarse de ellos".

Qué Karma no hace está ejecutando su sitio tal como está, que es lo que es la prueba de Extremo a extremo (E2E). En principio, podría usar los métodos internos de Angular para recrear el sitio o sus piezas. Que, para piezas pequeñas, puede ser útil, y una forma rápida, por ejemplo, para probar directivas.

Sin embargo, no se recomienda lanzar código complicado dentro de sus pruebas. Cuanto más haces es más probable que cometas errores en ese código en lugar de lo que realmente estás probando.

Es por eso que personalmente no me gusta la forma complicada a menudo mencionada de métodos de prueba utilizando métodos de bajo nivel como $http. Funciona más limpio para aislar cualquier referencia a métodos de bajo nivel en métodos dedicados propios, cuya única responsabilidad es hacer solicitudes http. Estos métodos dedicados deben ser capaces de trabajar con real backend , no uno falso! Que puedes probar fácilmente-manualmente o incluso perfectamente bien con Karma corriendo con otra configuración especial , siempre y cuando no mezcles esa configuración con la que normalmente se usa para ejecutar Karma regular y rápido. Ahora, habiendo 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 regular Karma.

Para resumir. Uso 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é lo haría? Ejecutando Transportador podría ralentizar mis pruebas, derrotando el propósito de Karma. Es fácil ejecutar Protractor por separado.

Transportador

El transportador es:

Un ensayo de extremo a extremo framework para aplicaciones AngularJS. Protractor ejecuta pruebas contra su aplicación que se ejecuta en un navegador real, interactuando con ella como lo haría un usuario.

Así que El Transportadorhace exactamente lo que el Karma no - ejecuta tu aplicación final real. Esto revela su poder y limitaciones:

Ejecutar la aplicación completa es la única prueba final fiable de que su aplicación funciona como se espera. Puede escribir escenarios completos de historia de usuario y poner ellos en sus pruebas!

Pero es más difícil rastrear errores sin aislar unidades individuales de su código fuente. Esta es la razón por la que todavía necesita Karma para probar su código JavaScript primero.

Ahora quiero correr Transportador con Karma? Seguramente puedo ejecutarlos en ventanas terminales separadas, en paralelo. Podría, en principio, hacer que compartan archivos de prueba si lo necesito, pero normalmente prefiero no hacerlo. ¿Por qué? Porque quiero mantener mis pruebas pequeño con un solo propósito dedicado.

La única excepción sería un archivo que defina macros de prueba útiles para ambos corredores. Esto, sin embargo, no sería un archivo de prueba sino un archivo de definición de macro .

Aparte de eso, me gusta una clara separación entre mis pruebas. Los que se ejecutan con frecuencia y rápido, y los de la aplicación completa. Eso hace una clara separación entre cuando se usa Karma y cuando Transportador .