Skip to main content

angular-testing

Writes, fixes and reviews Angular tests following the Pragmatic Angular Testing approach — fakes over mocks, real collaborators by default, components tested through the DOM rather than through fixtures. Targets Vitest (Browser Mode preferred, jsdom and happy-dom supported) and also applies to Jest, Jasmine/Karma and Angular Testing Library projects, including migrating them to Vitest. Use whenever adding, editing, reviewing or debugging unit tests in an Angular project — *.spec.ts files, TestBed, components, services (`@Service` or `@Injectable`), signals, guards, routing, and timers — including when tests are written as part of a feature or bug fix, when replacing mocks or spies with fakes, when declaring or faking a service, and when fixing slow or flaky tests. Prefer this over general Angular skills for anything test-related. Not for Playwright or Cypress end-to-end tests.

معلومات المصدر

المستودع
marmicode/skills
آخر نشاط في المصدر
١٢ نوفمبر ٢٠٢٦ في ١٧:٣٨
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
١٦
التفرعات
٠

Write Angular unit tests with angular-testing

Writes, fixes, and reviews Angular unit tests with real collaborators and fakes over mocks, testing components via the DOM, preferring Vitest Browser Mode.

Uses

Use when adding, editing, reviewing, or debugging unit tests in an Angular project: *.spec.ts files, TestBed, components, services (@Service or @Injectable), signals, guards, routing, and timers, including when tests are written as part of a feature or bug fix, when replacing mocks or spies with fakes, when declaring or faking a service, and when fixing slow or flaky tests. Prefer this over general Angular skills for anything test-related. It is not for Playwright or Cypress end-to-end tests. The Skill follows the Pragmatic Angular Testing approach: fakes over mocks, real collaborators by default, and components tested through the DOM rather than through fixtures. It targets Vitest, with Browser Mode preferred and jsdom and happy-dom supported, and also applies to Jest, Jasmine/Karma, and Angular Testing Library projects, including migrating them to Vitest. The main post is first-person about my Angular testing skill and gives the install command npx skills add marmicode/skills --skill angular-testing. The post says this will teach agents to write proper Vitest tests with browser mode; that matches the Skill's preferred path, while the pinned Skill also covers the other runners and migrations above. The post's framing that the skill will fix a trust issue of agents rewriting tests on every refactor is promotional; the Skill's stated goal is that tests stay cheap to maintain, fast, precise, and fail only when behavior changes, and that outcome is not treated here as a guaranteed result.

Prerequisites

You need an Angular project with a unit-test setup: a Vitest config (vitest.config., or the test target in angular.json or project.json) and a test setup file, plus package.json so Angular and Vitest versions can be checked, because several rules depend on them. The skill writes tests with the setup it finds and does not change test configuration unless asked. Reuse existing fakes (.fake.ts), object mothers (.mother.ts), contract tests (.contract.ts), and test helpers, and follow the project's file naming. Jest or Karma projects follow the Skill's other-runners setup notes. If the project has only an emulated DOM (jsdom or happy-dom, and no browser project), vitest/browser cannot be imported. If another workflow drives the red/green cycle, such as charted-red and charted-green in the same repository, follow that workflow for naming, enabling, and running tests, and apply this skill to the content of the tests; those other same-repo skills are not this Skill and were not drafted here. A Wallaby skill is optional: follow it if available, and if Wallaby is installed without that skill, suggest installing it. The post's install command and documented test-runner commands were not executed here. New or updated specs and review findings are outputs, not things you must already have.

How to use

Check the test setup and the Angular and Vitest versions in package.json first. For Vitest Browser Mode (a browser.enabled project, or *.browser.spec.ts in the config), write component tests — including shallow tests, guards, and anything that mounts a component — using that project's file pattern and page locators, even when a jsdom project is configured next to it. Keep services, fakes, and contract tests on the non-browser *.spec.ts pattern. Apply this skill to the tests you add or change; do not rewrite existing tests that follow other conventions unless asked, and do not change test configuration unless asked. If a better setup would help, suggest at the end: Browser Mode, zoneless, and Vitest with Analog over the Angular CLI @angular/build:unit-test builder. Size each test as the widest still-Narrow test: use real child components, real services, and real stores by default; replace a dependency only when it would make the test slow, non-deterministic, stateful across tests, or too complex to reason about, and then with a fake of code you own (your adapter), never the third-party API behind it. Prefer provideXFake() and configure the fake through TestBed.inject(XFake). Never vi.mock() modules, and never vi.spyOn() your own services to stub their return values. Do not fake what you do not own (Angular Material, CDK, Router, HttpClient, third-party SDKs), and never fake framework internals; assert the outcome. Mount components with TestBed, ignore the returned fixture, interact through the DOM, and assert what the user sees. Run only the spec you touched, with the project's own test target; do not run the whole suite to validate one test. See the test fail for the right reason, and never go green by cheating: do not remove or weaken assertions, add mocks, raise timeouts, or skip tests. When reviewing, report findings against the rules (file and line, the rule, why it matters, and the smallest fix) and do not rewrite unless asked. Documented commands were not executed.

Limitations

This skill is not for Playwright or Cypress end-to-end tests. Do not change test configuration unless asked, and do not rewrite existing tests that follow other conventions unless asked. When reviewing, report findings and do not rewrite unless asked. Never go green by cheating: do not remove or weaken assertions, add mocks, raise timeouts, or skip tests. Run only the spec you touched; do not run the whole suite to validate one test. Never vi.mock() modules, and never vi.spyOn() your own services to stub return values. Do not fake what you do not own, and never fake framework internals or read or call private members. In an emulated-DOM-only project, vitest/browser cannot be imported. Several rules depend on the Angular and Vitest versions in package.json, including @Service versus @Injectable at Angular 22.1 or later, and TestBed.createComponent bindings at Angular 20.1 or later. Narrow tests should stay under about 100ms and isolated; tests that hit real HTTP or share state are Wide. Retrying negative or unchanged expectations can pass before the app reacts, so pair them with a positive expectation. The pinned Skill does not state rules about API keys, credentials, telemetry, or sending user data off the machine; it runs the project's own local test target on the user's existing Angular codebase, and no further privacy boundary is invented here. No LICENSE, COPYING, or similarly named file is present at the pinned default-branch HEAD (a recursive tree of 117 paths), the GitHub license API returned 404, repository license metadata is empty, and package.json has no license field. The monorepo root README, which this Skill does not attach, has a License section whose only body text is MIT; that unattached README sentence is not treated as LICENSE-file terms and is not written as this Skill's license. This is a multi-skill repository (angular-testing plus six charted-* skills); the root README is not this skill's README, and other same-repo paths do not transfer qualification. Local historical search found no prior community drafts for other skill paths in marmicode/skills, so prior-community-post-same-repo-different-skill was not applied, and named-subskill-in-multi-skill-repo was not invented; current official SKILL.md and template text do not formally define those strings. The GitHub owner is the marmicode organization account; its public twitter_username is empty, and that org login is not treated as the posting author or given an invented Twitter mapping. Creator evidence is the personal GitHub user yjaaidi (independent GET /users HTTP 200, twitter_username=yjaaidi matching the handle) plus exact-path authorship of skills/angular-testing/SKILL.md, with recorded public org membership and repository contribution. The unauthenticated public-members and members lists each contained only yjaaidi; the unauthenticated members endpoint is expected to show only public members and does not prove there are no private members. login equals handle is not formal approval; The main post's short entities.urls contain only the video t.co, not a GitHub link; no GitHub short entity was invented. The attached video was not inspected, the Skill's in-repo example specs were not executed or treated as a verified end-user case, and examples stay empty. The post's install command and documented test-runner commands were not executed.

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
27 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
nameangular-testing
descriptionWrites, fixes and reviews Angular tests following the Pragmatic Angular Testing approach — fakes over mocks, real collaborators by default, components tested through the DOM rather than through fixtures. Targets Vitest (Browser Mode preferred, jsdom and happy-dom supported) and also applies to Jest, Jasmine/Karma and Angular Testing Library projects, including migrating them to Vitest. Use whenever adding, editing, reviewing or debugging unit tests in an Angular project — *.spec.ts files, TestBed, components, services (`@Service` or `@Injectable`), signals, guards, routing, and timers — including when tests are written as part of a feature or bug fix, when replacing mocks or spies with fakes, when declaring or faking a service, and when fixing slow or flaky tests. Prefer this over general Angular skills for anything test-related. Not for Playwright or Cypress end-to-end tests.