Angular TestBed with Karma

What TestBed Actually Does

TestBed.configureTestingModule() creates a lightweight, isolated Angular module specifically for a single test — declaring the component/service under test, plus any dependencies (real or mocked) it needs. This mirrors how Angular's real dependency injection and module system work in your actual application, but scoped down to exactly what one test needs.

import { TestBed } from '@angular/core/testing';
import { GreetingComponent } from './greeting.component';

describe('GreetingComponent', () => {
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [GreetingComponent]
    }).compileComponents();
  });

  it('creates the component', () => {
    const fixture = TestBed.createComponent(GreetingComponent);
    expect(fixture.componentInstance).toBeTruthy();
  });
});

This is a standard Jasmine spec — describe/it/beforeEach — with TestBed calls providing the Angular-specific setup Karma alone knows nothing about.

Core TestBed API Surface

TestBed.configureTestingModule({ declarations, imports, providers })
  .compileComponents();          // async, compiles templates/styles

TestBed.createComponent(MyComponent);   // returns a ComponentFixture
TestBed.inject(MyService);               // resolves a provider from the testing module
TestBed.resetTestingModule();             // usually called automatically between tests

• configureTestingModule() accepts the same declarations/imports/providers shape as a real NgModule.
• compileComponents() is asynchronous because it may need to resolve external templates/styles.
• TestBed.inject() is the modern replacement for the older TestBed.get() API.
• Angular automatically resets the testing module between specs, so each it() starts from a clean state.

TestBed Cheat Sheet

The core methods you'll use in nearly every Angular Karma spec.

Providing Mock Dependencies

providers inside configureTestingModule() is where you substitute real dependencies with test doubles — commonly Jasmine spy objects — so a unit test doesn't need a real HTTP backend, real routing, or other heavy real-world dependencies.

const apiServiceSpy = jasmine.createSpyObj('ApiService', ['getUsers']);
apiServiceSpy.getUsers.and.returnValue(of([{ id: 1, name: 'Ada' }]));

await TestBed.configureTestingModule({
  declarations: [UserListComponent],
  providers: [{ provide: ApiService, useValue: apiServiceSpy }]
}).compileComponents();

jasmine.createSpyObj() is the standard way to build a mock object with several spied-on methods at once.

How TestBed and Karma Actually Relate

It's worth stating plainly: Karma has no idea TestBed exists. Karma serves and runs your compiled spec files, and Jasmine executes the describe/it blocks inside them — TestBed is simply Angular-authored code, imported and called from within those Jasmine specs, exactly like any other library your test code happens to use.

Common Mistakes

• Forgetting compileComponents() is asynchronous and not awaiting/returning it correctly in beforeEach.
• Providing real, heavy services (like an actual HTTP client) instead of a lightweight mock or spy object.
• Assuming TestBed is a Karma feature rather than an entirely separate Angular testing utility.
• Not resetting spy call history between specs when a single spy object is reused across several tests.

Key Takeaways

• TestBed creates an isolated Angular testing module scoped to a single test file's needs.
• configureTestingModule() mirrors a real NgModule's shape: declarations, imports, and providers.
• Providing spy objects for dependencies is the standard way to isolate a unit test from real services.
• Karma runs the Jasmine specs; TestBed is Angular-authored code called from within those specs, not a Karma feature.