close

DEV Community

ss
ss

Posted on

I built a local-only VS Code extension for generating Angular TestBed specs

Angular component tests often start with the same chores:

  • configure TestBed
  • import the component
  • provide shallow dependency stubs
  • set required inputs
  • create the fixture
  • add the first creation assertion

I built ngTestFoundry to generate that first draft from Angular component
source.

Marketplace:

https://marketplace.visualstudio.com/items?itemName=sshyeri.ng-test-foundry

Public docs/support:

https://github.com/sshyeri/ng-test-foundry-public

What it does

ngTestFoundry is a VS Code extension that generates:

  • Angular TestBed .spec.ts files
  • CSF3 Storybook .stories.ts files

It runs locally. Component source is not sent to a server.

The goal is not to pretend generated tests are finished. The goal is to remove
the boring first-draft work so developers can review and adapt generated output
like normal code.

Why deterministic instead of AI magic?

I wanted the output to be repeatable and inspectable.

ngTestFoundry statically analyzes the component source. When it can infer
something confidently, it generates it. When it is unsure, it leaves an explicit
TODO instead of silently guessing.

That makes the tool less flashy, but easier to trust in real codebases.

Best fit today

The current best fit is:

  • Angular 17.3+ standalone components
  • input()
  • model()
  • output()
  • inject()
  • @Input()
  • @Output()

It can generate Jasmine/Jest-style TestBed specs and CSF3 Storybook stories.

Free vs Pro

Free:

  • generate a spec for the active component
  • generate a story for the active component

Pro:

  • batch-generate specs across a workspace
  • batch-generate stories across a workspace
  • use custom Eta templates

Pro is about workflow scale and customization. The core generator is the same.

Current limits

The tool is intentionally honest about current limits:

  • Non-standalone components are not fully supported yet because NgModule graph resolution is not implemented.
  • Dependency mocks are shallow.
  • Vitest output is planned but not implemented yet.

What feedback would help most

If you use Angular standalone components, I would love feedback on one real
component from your workspace.

The most useful questions:

  • Did the generated spec compile?
  • Was the TestBed setup useful?
  • Which Angular pattern was missing?
  • Did the TODOs help, or were they noisy?
  • Would batch generation save time in your workspace?

Feedback thread:

https://github.com/sshyeri/ng-test-foundry-public/issues/1

Roadmap voting:

https://github.com/sshyeri/ng-test-foundry-public/issues/2

Top comments (0)