utilizar uso usar transportador redondo para niños medir hacer grados facil dibujar con como angulos angulo javascript angularjs testing protractor karma-runner

javascript - uso - dibujar angulos



¿Se pueden usar el transportador y el karma juntos? (2)

Si Protractor reemplaza a Angular Scenario Runner para las pruebas E2E, ¿significa eso que todavía podré usarlo con Karma como mi marco de prueba E2E?


No recomendado por el actual mantenedor de transportador:

https://github.com/angular/protractor/issues/9#issuecomment-19927049

Transportador y Karma no deben usarse juntos; en cambio, proporcionan sistemas separados para ejecutar pruebas. El transportador y el Karma cubren diferentes aspectos de las pruebas: el objetivo principal del Karma es realizar pruebas unitarias, mientras que el transportador se debe utilizar para realizar pruebas de extremo a extremo.

Protractor está construido sobre WebDriverJS, que utiliza un servidor Selenium / WebDriver para provisionar navegadores y ejecutar la ejecución de pruebas. Los ejemplos de WebDriverJS puro se pueden encontrar aquí: http://code.google.com/p/selenium/wiki/WebDriverJs

Y

https://github.com/angular/protractor/issues/9#issuecomment-19931154

Georgios: creo que tiene sentido mantener separado el Transportador y el Karma; para las pruebas de extremo a extremo, deseas la conducción de eventos nativos y la flexibilidad de un controlador de página web, mientras que para las pruebas de unidad necesitas una ejecución rápida y autoverificación de archivos.


ACTUALIZAR. Aquí hay un paquete simple que he creado para agregar la 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 . Las preguntas frecuentes de Karma en realidad se refieren a Adapter para Scenario Runner de Angular , que, sin embargo, parece estar abandonado, con Transportador recomendado en su lugar.

Karma

Karma es un corredor de prueba que ejecutará los archivos JavaScript especificados en su archivo de configuración explícitamente o utilizando node-globs . (Para plantillas externas sin JavaScript, la Guía de pruebas unitarias de Angular recomienda usar el preprocesador html de Karma para compilarlas en JavaScript primero).

Estos pueden ser todos sus archivos fuente, algunos de ellos, algunos de ellos más algunos archivos adicionales o archivos irrelevantes para su proyecto, solo proporcionan alguna configuración adicional, ¡lo que usted quiera! Puede tener múltiples archivos de configuración de karma para diferentes propósitos, que puede ejecutar en paralelo o uno a 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 de origen, y recibe comentarios inmediatos, ¡lo cual es brillante! ¡Lo único negativo es el informe de error "ruidoso" que con suerte mejorará!

Karma no es solo para pruebas unitarias

La prueba de unidad es para una sola unidad de su código fuente. En el caso de Angular, una unidad típica es un componente angular ( Service, Factory, Provider, Controller, Filter, Directive etc.). Recuerde mantener sus Controllers delgados, por lo tanto, demasiadas pruebas de unidad para estos últimos es una señal de advertencia.

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 se deben probar al mismo tiempo. En su lugar, deben ser "burlados", por ejemplo, reemplazados por algo simple como instancias ficticias. Angular proporciona un gran soporte de entorno simulado . Lo ideal es que quiera ver todos esos simulacros directamente dentro de sus pruebas, por lo que nunca debe preguntarse de dónde provienen todas esas dependencias.

Karma es tan útil para las pruebas de integración , donde un grupo de unidades de código fuente se prueba conjuntamente, y solo se burlan de algunas de sus dependencias . Es importante recordar que cualquier dependencia se proporciona de forma predeterminada desde los módulos de código fuente (siempre que esos módulos se hayan inyectado directamente en las 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 la característica principal de Karma . Esto significa que desea evitar cualquier solicitud de servidor, cualquier consulta de base de datos, cualquier cosa que pueda llevar más tiempo que fracciones de segundos. (¡ De lo contrario, NO será rápido! ) Esos procesos largos son los que quiere burlarse . Esto también explica por qué es una mala práctica poner servicios de bajo nivel como $http directamente dentro de sus controladores o en cualquier unidad de lógica de negocios complicada. Al incluir esos servicios de comunicación externa 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 es una prueba de extremo a extremo (E2E). En principio, podría usar los métodos internos de Angular para recrear el sitio o sus piezas. Lo cual, para piezas pequeñas, puede ser útil, y de una manera rápida, por ejemplo, para probar directivas.

Sin embargo, no es una forma recomendable de arrojar código complicado dentro de sus pruebas. Cuanto más lo hagas, más posibilidades hay de que cometas errores en ese código en lugar de lo que en realidad estás probando.

Es por eso que personalmente me desagrada la forma complicada de probar métodos a menudo usando métodos de bajo nivel como $http . Funciona de manera más limpia para aislar cualquier referencia a métodos de bajo nivel en métodos propios propios, cuya única responsabilidad es realizar solicitudes http. ¡Estos métodos dedicados deberían poder funcionar con un back-end real , no falso! Que puedes probar fácilmente, de forma manual o incluso perfectamente bien con Karma corriendo con otra configuración especial , siempre y cuando no mezcles esa configuración con la que usualmente usas para ejecutar Karma de manera regular y rápida. Ahora, al probar sus pequeños servicios dedicados, puede burlarse de ellos con seguridad y facilidad para probar su otra lógica y poner estas pruebas en su configuración de Karma normal.

Para resumir. Usa 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 Protractor ? ¿Por qué habría? Ejecutar Prolongador ralentizaría mis pruebas, derrotando el propósito de Karma . Es fácil ejecutar el transportador por separado.

Transportador

Protractor es:

un marco de prueba de extremo a extremo para aplicaciones AngularJS. Protractor ejecuta pruebas contra su aplicación ejecutándose en un navegador real, interactuando con ella como lo haría un usuario.

Entonces, Protractor hace exactamente lo que Karma no hace: ejecutar su verdadera aplicación final. Esto revela su poder y sus limitaciones:

Ejecutar la aplicación completa es la única prueba final confiable de que su aplicación funciona como se espera. ¡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 esto que todavía necesita que Karma pruebe su código JavaScript primero.

¿Ahora quisiera ejecutar Transportador con Karma ? Seguramente puedo ejecutarlos en ventanas de terminal separadas, en paralelo. Podría, en principio, hacer que compartan archivos de prueba si es necesario, pero normalmente preferiría no hacerlo. ¿Por qué? Porque quiero mantener mis pruebas pequeñas con un único propósito dedicado.

La única excepción sería un archivo que define 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 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 un transportador .