Permítanme hablar brevemente con ustedes acerca de las pruebas angulares.
¿Cómo diseñas tus aplicaciones angulares para que sean probables?
¿Cómo se diseñan las pruebas para su aplicación angular?
¿Cómo ejecuta las pruebas y se asegura de que
su aplicación angular esté satisfaciendo todas las pruebas que ha escrito
incluso mientras está desarrollando su aplicación angular?
Ahora aquí es donde también hablaría brevemente sobre el desarrollo impulsado por pruebas
de aplicaciones angulares.
Curiosamente, angular en sí mismo se ha construido desde cero para permitir las pruebas,
para ser parte del desarrollo de su aplicación angular.
La fuerza principal detrás angular Misko Hevery era él mismo un ingeniero de pruebas de Google y, por lo tanto,
su influencia en el diseño angular para ser probable desde
ground up se puede ver fácilmente en todo el marco.
Así que, angular en sí mismo como has entendido de las conferencias y ejercicios anteriores,
es de naturaleza modular.
Así que los módulos de angular junto con los componentes y
sus plantillas y luego los servicios y las tuberías y las directivas,
significan que angular se presta fácilmente para ser probado.
Ahora, debido a que la aplicación angular en sí está compuesta de estas diversas partes,
puede probar cada una de esas partes en aislamiento primero
incluso antes de que se conviertan en parte de toda la aplicación angular.
El segundo aspecto es el mecanismo de inyección de dependencia que angular aprovecha
para apoyar la combinación de las diversas partes de
su aplicación angular en sí significa que puede reemplazar fácilmente las burlas
por esas dependencias dentro de
sus diversas partes del angular aplicación y llevar a cabo pruebas.
He usado la palabra simulacro en,
en la frase anterior llegará a entender
que en un poco más de detalle y más que, diapositivas posteriores.
Aquí es donde necesitamos ser conscientes de
un enfoque para hacer el desarrollo de aplicaciones llamado desarrollo impulsado por pruebas.
En el desarrollo basado en pruebas, como puede entender por el nombre en sí,
significa que primero escribe pruebas automatizadas para
toda la funcionalidad que desea implementar dentro de su aplicación.
Así que primero viene la prueba,
a partir de entonces escribes tu código de aplicación para pasar la prueba.
Entonces, la prueba en sí especifica qué funcionalidad desea implementar.
A partir de entonces, escribe el código para implementar esa funcionalidad.
Dado que ya tiene la prueba en su lugar,
puede probar para ver si la implementación que hace satisface la prueba o no.
Ahora, por supuesto, una vez que su realización de su funcionalidad satisface la prueba,
siempre puede refactorizar el código para cumplir con sus estándares de ingeniería de software.
Pero incluso después de eso,
puede volver a probar el código para asegurarse de que todavía cumple
los requisitos especificados dentro de
esa prueba específica que usa dentro de su desarrollo impulsado por pruebas.
Así que, de hecho, el desarrollo impulsado por pruebas es
un enfoque muy viable para diseñar
buena aplicación desde cero para ser completamente probado.
Ahora, cuando hablamos de pruebas,
puedes abordar las pruebas desde varios aspectos diferentes.
Lo primero y más importante es que si su aplicación
en sí misma se implementa como varias piezas,
como componentes, como servicios, como directivas,
como las tuberías que está implementando dentro de su aplicación.
Esto significa que puede probar fácilmente cada una de estas unidades individuales de forma aislada.
Así que ahí es donde las pruebas unitarias pasan a primer plano.
Prueba unitaria significa que está probando las unidades individuales de código,
asegurándose de que esa unidad individual
en particular satisfaga la funcionalidad que se supone que debe soportar,
y que la funcionalidad y la lógica dentro de esa pieza de código se implementen correctamente.
Ahora aislar la unidad y probarla es muy,
muy útil para descubrir la mayoría de los problemas iniciales dentro de su,
dentro de su código y luego solucionarlos incluso antes de integrar ese parche en el código.
Ahora una vez que empieces a integrar estas partes en el conjunto,
se vuelve aún más engorroso poder llevar a cabo pruebas detalladas de tu código.
Entonces, por lo tanto, las pruebas unitarias aisladas forman la primera línea
de defensa contra errores cuando está desarrollando su aplicación,
específicamente su aplicación angular.
Ahora como vemos con un angular,
tenemos una clara separación entre los componentes angulares y el propio DOM.
Así que dentro de un componente, por ejemplo, allí,
la lógica de su componente se implementa completamente en
el código mecanografiado que implementó dentro de un componente que archivos mecanografiados.
Y luego el DOM en sí se controla a través de
la plantilla que ha diseñado para su componente angular.
Así que Beta en sí, se ve la clara separación entre los dos.
Entonces simplemente podría probar la lógica de
su código de componente en sí mismo sin escribir una plantilla vertical.
Pero entonces también podría considerar los dos juntos y luego evaluar esos aspectos.
Como veremos en el ejercicio que sigue a esta conferencia,
realmente haremos ambos enfoques.
No solo eso, el hecho de que angular use la inyección de dependencia
significa que puede inyectar dependencias simuladas dentro de su aplicación.
Cuando digo simulacro, quiero decir, por ejemplo,
si su componente depende de un servicio particular, siempre puede implementar
un servicio simulado que imita el comportamiento del servicio
y luego reemplace en su lugar mientras está probando el componente para que pueda mantener
su componente independiente de cómo se implementa realmente el servicio.
Siempre y cuando la interfaz entre su componente y el servicio esté correctamente diseñada
, puede sustituir un servicio simulado en su lugar y aún así probar su componente.
Allí, desde el simulacro,
puede controlar fácilmente lo que se suministra al componente desde el servicio.
Así que este enfoque le permite hacer pruebas unitarias
con gran detalle dentro de su aplicación angular.
Aquí es donde la disponibilidad de marcos de prueba como «Jasmine».
Entonces, lo que Jasmine proporciona es
un marco de pruebas impulsado por el comportamiento que está completamente diseñado en JavaScript.
Ahora, este marco de Jasmine es un marco general que
está disponible para probar cualquier aplicación JavaScript.
Angular adopta Jasmine como el enfoque para especificar nuestras pruebas para otras partes angulares,
sus componentes, los servicios y varios aspectos de nuestra aplicación angular.
Ahora, dentro de Jasmine, Jasmine usa dos cosas que vienen en tu ayuda.
Uno es el uso de una función de «describir».
La función «describe» le permite agrupar un conjunto de pruebas y luego
ejecutar estas pruebas juntas como un solo grupo de pruebas.
Cuando escribimos el código en el ejercicio me verás
adjuntando un conjunto de pruebas dentro de una función de descripción.
Luego escribimos nuestro código para nuestro,
el código Jasmine, para nuestras pruebas angulares.
Ahora dentro de estas funciones de «describir» también usarás lo que se llama «it» funciones.
Las funciones «it» le permiten especificar
pruebas individuales que desea realizar en su aplicación angular.
Así que ahí es donde me verán especificando «eso» y luego especificarán que
la naturaleza de la prueba en particular y luego
diseñarán el código para esa prueba en particular con una función en «eso».
Así que mientras diseñamos el código en el ejercicio busque el «describe» y
el «it» dentro de sus aplicaciones de prueba angular.
Una vez que haya diseñado la prueba con el framework Jasmine,
Karma es una herramienta de línea de comandos basada en JavaScript
que le permite realizar estas pruebas automáticamente.
Ahora, Karma junto con Jasmine,
le permite llevar a cabo pruebas para su aplicación angular.
Ahora con Karma, lo que Karma apoya,
es que le permite generar
un servidor web dentro del cual usted carga el código fuente de su aplicación y
luego Karma utiliza un navegador para llevar a cabo las pruebas reales de sus diversas unidades.
Así que aquí es donde cuando ejecuta sus pruebas usando Karma,
verá Karma apilando un navegador,
si se trata de una ventana de navegador de un navegador existente o
si usaría algo llamado PhantomJS que inicia
un navegador fantasma detrás de las escenas para llevar a cabo la prueba.
No importa, pero Karma utiliza
el navegador en un momento para llevar a cabo la prueba para su aplicación angular.
Como verá en el ejercicio que sigue,
aquí es donde si uno de sus colegas sigue insistiendo en que su implementación de
una pieza particular de su aplicación angular es
correcta y sigue enfatizando el punto,
siempre puede diseñar algunas pruebas usando Jasmine y
Karma y luego llevar a cabo las pruebas y si las pruebas fallan,
siempre puedes refutar su argumento.
Así que es cuando puedes girar,
dar la vuelta a tu colega y decir,
mi Karma corrió sobre tu dogma.
Ahora, por supuesto, sus aplicaciones angulares no están completamente desprovistas
de la participación del marco angular en sí.
Su componente no puede ser diseñado por usted mismo sin
usando muchas de las funcionalidades de biblioteca que angular proporciona para usted,
aunque parte de la lógica básica se puede probar independientemente de angular.
Lo que llamamos como pruebas aisladas.
Pero, cada vez más,
encontrará que a menos que usted en,
quiere que el soporte angular en sí mismo
no será capaz de llevar a cabo gran parte de la prueba de
sus partes angulares ya sean componentes o servicios o tuberías o directivas.
Así que aquí es donde las utilidades de pruebas angulares proporcionan
un entorno de prueba que le permite realizar
las pruebas unitarias dentro de su aplicación angular.
Así que las utilidades de pruebas angulares como me verán usando en los ejercicios,
en el próximo ejercicio,
nos proporcionarán ciertas implementaciones de funcionalidad angular que usa
dentro de sus pruebas con el fin de configurar el entorno donde puede llevar a cabo sus pruebas.
Entonces, aquí es donde la interacción con el entorno angular,
en lugar de usar las implementaciones angulares reales,
usará estas utilidades de prueba que proporcionarán
funcionalidad suficiente para permitirle llevar a cabo las pruebas.
Y aquí es donde el TestBed que vamos a utilizar
dentro de nuestra aplicación angular es muy, muy útil.
El TestBed esencialmente crea un modular de prueba angular.
Como te das cuenta, tus componentes no existen por sí mismos.
Sus componentes deben ser incluidos dentro de un módulo NG.
Ahora no puede simplemente usar un módulo NG estándar para llevar a cabo sus pruebas.
Así que ahí es donde TestBed,
que es compatible con la utilidad de prueba angular,
le proporciona un entorno de módulo NG que le permite probar sus componentes.
Por lo tanto, dentro del TestBed,
usará algo llamado TestBed Create Component para crear
un componente individual y una instancia del componente para llevar a cabo las pruebas sobre eso.
Y cuando haces eso
el TestBed te da acceso a algo llamado ComponentFixture,
ComponentFixture es algo que te proporciona un mango que te permite rodear
tu componente con suficiente funcionalidad para que el componente pueda ser probado por sí mismo.
El accesorio proporciona acceso al componente en sí y
luego también a través de eso vamos a utilizar algo llamado el DebugElement.
Me verán usando eso en el ejercicio que sigue.
El DebugElement le da acceso al DOM,
que es la plantilla que se admite como parte de su componente.
Por lo tanto, puede hacer manipulaciones en el DOM como hacer clic en elementos en el DOM,
obtener acceso a un elemento DOM y luego leer lo que está encerrado
dentro de esos elementos Dom y así sucesivamente lo que le permitirá llevar a cabo las pruebas.
Ahora, antes de continuar con el ejercicio,
quiero que sean conscientes de algunas de estas cosas para que cuando las encontremos en
el ejercicio mismo vean por qué estoy haciendo uso de cada una de estas diferentes piezas.