ngMock unit tests (module, inject, $controller) en Angular moderno

module() e inject() de ngMock pasan a ser TestBed. Una prueba importa el componente standalone, reemplaza sus dependencias con dobles de prueba y revisa el DOM renderizado.

Antes · AngularJS

describe('CartCtrl', function () {
  var ctrl, CartService;
  beforeEach(module('app'));
  beforeEach(inject(function ($controller, _CartService_) {
    CartService = _CartService_;
    spyOn(CartService, 'total').and.returnValue(30);
    ctrl = $controller('CartCtrl');
  }));

  it('shows the total', function () {
    expect(ctrl.total).toBe(30);
  });
});

Después · Angular

describe('CartComponent', () => {
  it('shows the total', () => {
    TestBed.configureTestingModule({
      imports: [CartComponent],
      providers: [{ provide: CartService, useValue: { total: () => 30 } }],
    });

    const fixture = TestBed.createComponent(CartComponent);
    fixture.detectChanges();

    const total = fixture.nativeElement.querySelector('.total');
    expect(total.textContent).toContain('30');
  });
});

Qué cambia

module('app') cargaba la aplicación completa; TestBed carga solo el componente bajo prueba y los providers que declares.
$controller probaba el controlador sin su template; un fixture también renderiza el template, así que la prueba cubre lo que ve el usuario.
La inyección con guiones bajos (_CartService_) pasa a ser TestBed.inject(CartService).

Consejo de migración. No portes las pruebas viejas línea por línea. Conserva sus nombres como lista de comportamientos y reescribe cada caso contra el componente renderizado; los component harnesses de @angular/cdk/testing ayudan a dejar las consultas al DOM fuera del cuerpo de la prueba.

Relacionado

¿Planeas una migración o una plataforma de microfrontends?

En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.

Escríbeme por LinkedIn