Przejdź do treści
Biblioteka skilli
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.

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

  1. Input
  2. Context Detection
  3. How to Generate
  4. Test File Structure
  5. Rules
  6. Component Library Contributions
  7. 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

RepozytoriumWynikLicencja
Ta strona · patternfly/ai-helpers100MIT
rh-uxd/ai-helpers100MIT

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.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.