Programowanie · Testowanie
pf-test-gen
/pf-test-gen
Generuje plik testów jednostkowych dla komponentu React z użyciem Testing Library, aby zwiększyć pokrycie nowego lub istniejącego kodu.
Dla kogo
- Autor
- patternfly ↗
- Repozytorium
- ai-helpers ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 11.08.2026
Ocena i bezpieczeństwo
100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 1
Przestarzałość
Brak sygnałów. Repozytorium zmienione 11.08.2026, bez odwołań do wycofanych modeli i API.
Licencja
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Generuje plik testów jednostkowych dla komponentu React z użyciem Testing Library, aby zwiększyć pokrycie nowego lub istniejącego kodu.
Oryginalny opis (EN)
Generate a unit test file for a React component using Testing Library. Use when adding test coverage to new or existing components.
Jak działa
- Input
- Context Detection
- How to Generate
- Test File Structure
- Rules
- Component Library Contributions
- Output
Sekcje z nagłówków SKILL.md, w oryginale · 121 linii, 625 słów
Podgląd SKILL.md
---
name: pf-test-gen
description: Generate a unit test file for a React component using Testing Library. Use when adding test coverage to new or existing components.
---
Generate a comprehensive unit test file for the given React component.
## Input
The user will provide a component file path or component code. Read the component source before generating tests.
## Context Detection
Determine if the component is part of a component library (patternfly-react, patternfly-chatbot, or similar) or a consumer application. Check whether the component lives in a library source tree or an application codebase. This determines the testing approach — see "Component Library Contributions" below for adjustments.
## How to Generate
1. Identify what the component does: rendering, user interactions, conditional states, async operations.
2. Look up any PatternFly components used so you understand their expected props and behaviors.
3. Generate a complete test file covering all branches.
## Test File Structure
```typescript
import { render, screen, waitFor } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
```
Organize tests into `describe` blocks by behavior: `rendering`, `user interactions`, `conditional rendering`, `async operations`, `accessibility` — only include sections that apply.
## Rules
**Queries** — use in this order:
1. `getByRole` (always first choice)
2. `getByLabelText`
3. `getByText`
4. `getByTestId` (last resort only)
**Interactions** — always `userEvent`, never `fireEvent`:
```typescript
const user = userEvent.setup();
await user.click(screen.getByRole("button", { name: "Save" }));
```
**Mocking** — mock at the network boundary:
- Mock API calls and external services
- Never mock child components or PatternFly components
- Place all mocks at top of file
- `jest.clearAllMocks()` in `beforeEach`
**Async** — prefer `findBy*` over `waitFor` for waiting on elements:
```typescript
expect(await screen.findByText("Success")).toBeInTheDocument();
```
Use `waitFor` only for non-query assertions:
```typescript
await waitFor(() => {
expect(onComplete).toHaveBeenCalled();
});
```
**What to test:**
- Component behavior from the user's perspective
- All conditional rendering branches (loading, error, empty, populated)
- User interactions and their effects
- Callback invocations with correct arguments
**What NOT to test:**
- PatternFly component internals (they're already tested)
- Implementation details (state, internal functions)
**CSS classes** — test with `toHaveClass` when classes are part of the component's public API (e.g., modifier classes, conditional styling). Don't test internal or structural classes that are implementation details.
## Component Library Contributions
When testing a component within a component library (patternfly-react, patternfly-chatbot, etc.), these adjustments apply. The "user" of a library component is a developer consuming its API — so test the API contract.
**Mocking child components** — default to mocking child components for unit isolation:
```typescript
jest.mock('../Header', () => ({
Header: ({ children, ...props }) => <h1 {...props}>{children}</h1>
}));
```
Exception: don't mock when the parent-child interaction is the behavior being tested (e.g., a composite component where orchestration between children is the point).
**Coverage checklist** — cover these for every library component:
1. Default rendering with only required props
2. Prop variations — each prop value produces expected output
3. Custom className — merges with internal classes
4. Spread props — extra props forwarded to root element
5. Children — renders children correctly
6. Callbacks — event handlers fire with correct arguments
7. Conditional rendering — elements show/hide based on props
8. Accessibility — ARIA roles, labels, keyboard interaction
**Snapshots** — use for component structure and element ordering. Do not use snapshots to verify CSS classes — use `toHaveClass` instead:
```typescript
const { asFragment } = render(<MyLayout />);
expect(asFragment()).toMatchSnapshot();
```
**File organization** — one test file per exported component, colocated with the source:
```text
Button/
├── Button.tsx
├── Button.test.tsx
├── ButtonVariant.tsx
└── ButtonVariant.test.tsx
```
**PatternFly-specific conventions** — follow the [PatternFly testing wiki](https://github.com/patternfly/patternfly-react/wiki/React-Testing-Library-Basics,-Best-Practices,-and-Guidelines). Use `test()` for top-level tests and `it()` inside `describe()` blocks:
```typescript
test('renders with default props', () => { ... });
describe('when disabled', () => {
it('has disabled attribute', () => { ... });
it('does not fire onClick', () => { ... });
});
```
## Output
Output the complete test file ready to save. Name it `ComponentName.test.tsx` matching the source file.
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · patternfly/ai-helpers | 100 | MIT |
| rh-uxd/ai-helpers | 100 | MIT |
Migawka bazy z 28.10.2026 · wersja paczki e92877bfe838 (skrót SHA-256 całej paczki)
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100react-native-testing
Testuje komponenty React Native z Jest i React Native Testing Library. - 100react-testing
Testuje komponenty React z React Testing Library oraz Jest lub Vitest. - 100frontend-test
Generuje testy komponentów frontendowych (React Testing Library, Vue Test Utils, snapshoty) dla istniejących komponentów. - 100testing-react
Pisze testy komponentów, hooków i utilities w React i TypeScript przy użyciu Vitest oraz React Testing Library. - 100senior-qa
Generuje testy jednostkowe i E2E dla React i Next.js w Jest, React Testing Library i Playwright oraz analizuje pokrycie kodu. - 100frontend-testing
Generuje testy Vitest i React Testing Library dla komponentów, hooków i funkcji pomocniczych we frontendzie, w tym pliki spec, pokrycie kodu oraz testy jednostkowe i integracyjne.