Cerrando la brecha entre la DI basada en constructor y las pruebas DI basadas en inyección sin TestBed

Angular 14 introdujo la capacidad de usar la función de inyección en clases como componentes, directivas y tuberías. Los autores de bibliotecas han adoptado esta función y muchos han eliminado la Inyección de dependencias ('DI') basada en constructores. También inspiró unas funciones reutilizables llamadas Funciones DI .

Hay muchos enfoques que usan TestBed que le permiten probar e incluso simular las dependencias proporcionadas por la función Inyectar.

Sin embargo, ¿qué sucede si no desea utilizar TestBed? Tal vez debido a problemas de rendimiento , tal vez prefiera aislar las pruebas unitarias del DOM de forma predeterminada, o tal vez haya notado que Angular está introduciendo utilidades para facilitar la ejecución de funciones en un contexto de inyección con proveedores.

tl; dr:

• ejecutar npm i @ngx-unit-test/inject-mocks -Dpara instalar funciones de utilidad para realizar pruebas unitarias de cualquier clase o función de Angular sin TestBed.

Este artículo (1) resume un componente que necesita pruebas unitarias, (2) demuestra cómo probar ese componente en Angular 15+ sin TestBed y (3) muestra cómo probar una función DI sin TestBed.

1. La configuración: un componente que necesita pruebas unitarias

Aquí hay un HomeComponent simple escrito en Angular 15 que usa la función de inyección:

El componente inyecta una WidgetsFacade, accede a algunos observables expuestos por esa fachada y activa un método de fachada durante ngOnInit.

2. Proporcionar dependencias simuladas

Entonces, ¿cómo podría burlarse de WidgetsFacade inyectado sin usar TestBed?

Si solo ejecuta la especificación sin TestBed, obtiene este error:

Para brindar el servicio y simular sus funciones hay dos pasos:

Primero, cree un método de utilidad que envuelva el @angular/coreInyector:

Esta utilidad aprovecha la clase integrada de Angular Injectorpara proporcionar automáticamente dependencias a una clase determinada. Puede notar que el nombre es classWithProvidersy no componentWithProviders. ¡Eso se debe a que la utilidad funciona con Componentes, Servicios, Directivas y Tuberías!

En segundo lugar, use classWithProvidersen un archivo de especificaciones:

Veamos cada paso en el archivo de especificaciones:

1. Declarar una variable facadeMock escrita como Partial<WidgetsFacade>. Use Parcial para obtener la inferencia de tipo en el siguiente paso.
2. Asignar objeto simulado : crea un objeto JavaScript y asígnalo jest.fn()al método que necesitas simular.
3. Obtener componente con contexto de inyección : ¡Gracias a la classWithProvidersutilidad, el componente devuelto tiene el proveedor simulado!

Una limitación classWithProviderses que no funciona con funciones de inyección de dependencia (funciones DI). La solución actual para probar las funciones DI implica TestBed.runInInjectionContext, que se lanzó en Angular 15.1.0 .

Sobre la base del ejemplo de TestBed, es posible crear una utilidad independiente que proporcione una solución similar para probar funciones DI con proveedores simulados:

De hecho, el equipo de Angular ya está trabajando en una nueva utilidad runInInjectionContext que reemplaza y amplía el método runInContext.

Conclusión

Las utilidades classWithProvidersy runFnInContextse inspiraron en el código fuente de Angular.io . He dado el paso adicional de agrupar estas utilidades en un paquete npm . Gracias a Josh Van Allen y Rafael Mestre por su comprensión y ayuda en el desarrollo de estas utilidades.

Acerca de HeroDevs

HeroDevs es un estudio de consultoría e ingeniería de software que se especializa en el desarrollo front-end. Nuestro equipo ha sido autor o coautor de proyectos como Angular CLI, Angular Universal, Scully, XLTS: soporte extendido a largo plazo para AngularJS, Vue2, Protractor y muchos otros. Trabajamos con nuevas empresas de rápido crecimiento y algunas de las empresas más grandes del mundo como Google, GE, Capital One, Experian, T-Mobile, Corteva y otras. Obtenga más información sobre nosotros en herodevs.com .