fix

Author: Vesperalin

PLAYWRIGHT_CONFIG_EXPLAINED.md

@@ -3,45 +3,54 @@
 ## 🎯 Kluczowe ustawienia
 
 ### `fullyParallel: false`
+
 **Co to robi:** Testy uruchamiają się jeden po drugim
 **Dlaczego:** Łatwiej debugować na początku. Zmień na `true` gdy będziesz mieć dużo stabilnych testów.
 
 ### `workers: 1`
+
 **Co to robi:** Tylko jedna przeglądarka w tym samym czasie
 **Dlaczego:** Stabilniejsze, łatwiej śledzić co się dzieje
 
 ### `trace: "on"`
+
 **Co to robi:** Zapisuje każdy krok testu (kliknięcia, nawigacja, itp.)
 **Jak zobaczyć:** `npx playwright show-trace playwright-report/trace.zip`
 **Kiedy:** Zawsze - zobaczysz dokładnie co poszło nie tak
 
 ### `screenshot: "only-on-failure"`
+
 **Co to robi:** Robi zdjęcie ekranu gdy test failuje
 **Gdzie:** `playwright-report/` folder
 
 ### `video: "off"`
+
 **Co to robi:** Nie nagrywa wideo
 **Dlaczego:** Trace + screenshoty wystarczą, wideo zajmuje dużo miejsca
 **Kiedy włączyć:** Jak będziesz mieć bardzo trudny do zreprodukowania bug
 
 ### `baseURL: "http://localhost:3000"`
+
 **Co to robi:** Możesz pisać `page.goto('/')` zamiast `page.goto('http://localhost:3000/')`
 **Przykład:**
+
 ```typescript
 // Zamiast tego:
-await page.goto('http://localhost:3000/dashboard');
+await page.goto("http://localhost:3000/dashboard");
 
 // Piszesz:
-await page.goto('/dashboard');
+await page.goto("/dashboard");
 ```
 
 ### `webServer`
+
 **Co to robi:** Automatycznie uruchamia `npm run dev` przed testami
 **Bonus:** `reuseExistingServer: true` - jeśli masz już uruchomiony dev server, użyje go (szybciej)
 
 ## 🚀 Jak używać
 
 ### Pierwszy test
+
 ```bash
 # Uruchom testy E2E
 npm run test:e2e
@@ -52,6 +61,7 @@ npm run test:e2e
 ```
 
 ### Gdy test failuje
+
 ```bash
 # Playwright automatycznie:
 # 1. Zrobi screenshot → playwright-report/
@@ -68,6 +78,7 @@ npm run test:e2e:report
 ```
 
 ### Debugowanie
+
 ```bash
 # Tryb debug - zatrzymuje test i pokazuje przeglądarkę
 npm run test:e2e:debug
@@ -83,26 +94,32 @@ npm run test:e2e:ui
 ## 💡 Tipsy
 
 ### 1. Zacznij od prostych testów
+
 ```typescript
-test('should load homepage', async ({ page }) => {
-  await page.goto('/');
+test("should load homepage", async ({ page }) => {
+  await page.goto("/");
   await expect(page).toHaveTitle(/Pathly/);
 });
 ```
 
 ### 2. Używaj UI mode podczas pisania testów
+
 ```bash
 npm run test:e2e:ui
 ```
+
 Zobaczysz na żywo co robi Twój test!
 
 ### 3. Trace to Twój najlepszy przyjaciel
+
 Gdy test failuje:
+
 1. Otwórz `npm run test:e2e:report`
 2. Kliknij na failed test
 3. Zobacz trace - zobaczysz DOKŁADNIE co się stało, krok po kroku
 
 ### 4. Nie martw się o wydajność na początku
+
 - `workers: 1` jest OK
 - `fullyParallel: false` jest OK
 - `trace: "on"` jest OK
@@ -112,18 +129,21 @@ Optymalizujesz później, gdy będziesz mieć dużo testów.
 ## 🎨 Kiedy zmienić ustawienia
 
 ### Masz już 10+ stabilnych testów?
+
 ```typescript
 fullyParallel: true,  // Szybsze testy
 workers: 4,           // 4 przeglądarki naraz
 trace: "retain-on-failure",  // Trace tylko przy failach
 ```
 
 ### Potrzebujesz wideo?
+
 ```typescript
 video: "retain-on-failure",  // Tylko przy failach
 ```
 
 ### Testujesz mobile?
+
 ```typescript
 projects: [
   { name: "chromium", use: { ...devices["Desktop Chrome"] } },
@@ -147,4 +167,3 @@ A: To "nagranie" testu - każdy klik, nawigacja, assertion. Bezcenne przy debugo
 
 **Q: Muszę testować na Firefox/Safari?**
 A: Na początku nie. Chromium wystarczy. Dodasz później jeśli będzie potrzeba.
-

VITEST_CONFIG_EXPLAINED.md

@@ -3,72 +3,86 @@
 ## 🎯 Kluczowe ustawienia
 
 ### `environment: "jsdom"`
+
 **Co to robi:** Symuluje środowisko przeglądarki (DOM, window, document)
 **Dlaczego:** Twoje komponenty React potrzebują DOM
 **Alternatywa:** `happy-dom` (szybszy, ale mniej kompatybilny) - zostań przy jsdom
 
 ### `globals: true`
+
 **Co to robi:** Możesz pisać `describe`, `it`, `expect` bez importów
 **Przykład:**
+
 ```typescript
 // Bez globals:
-import { describe, it, expect } from 'vitest';
+import { describe, it, expect } from "vitest";
 
 // Z globals (prostsze!):
-describe('MyComponent', () => {
-  it('should render', () => {
+describe("MyComponent", () => {
+  it("should render", () => {
     expect(true).toBe(true);
   });
 });
 ```
 
 ### `setupFiles: ["./src/test/setup-tests.ts"]`
+
 **Co to robi:** Uruchamia ten plik przed wszystkimi testami
 **Co jest w środku:**
+
 - `@testing-library/jest-dom` (matchery jak `toBeInTheDocument()`)
 - Mocki Next.js (`useRouter`, `usePathname`, itp.)
 - Mocki next-intl, next-themes
 - MSW (Mock Service Worker) setup
 
 ### `css: true`
+
 **Co to robi:** Nie failuje gdy importujesz CSS w komponentach
 **Przykład:**
+
 ```typescript
 // Bez css: true → ERROR
-import './Button.css';
+import "./Button.css";
 
 // Z css: true → OK ✅
-import './Button.css';
+import "./Button.css";
 ```
 
 ## 📊 Coverage (Pokrycie kodu)
 
 ### `reporter: ["text", "html"]`
+
 **Co to robi:**
+
 - `text` - pokazuje wyniki w terminalu
 - `html` - generuje stronę HTML w `coverage/index.html`
 
 **Usunięte:** `json` i `lcov` (niepotrzebne bez CI/CD)
 
 ### `thresholds: 60`
+
 **Co to robi:** Minimalny % pokrycia kodu
 **Zmienione z 70% na 60%** - łatwiej na początek
 
 **4 typy pokrycia:**
+
 - **lines:** % linii kodu które zostały uruchomione
 - **functions:** % funkcji które zostały wywołane
 - **branches:** % ścieżek (if/else) które zostały przetestowane
 - **statements:** % instrukcji które zostały wykonane
 
 **Co się stanie jak spadnie poniżej 60%?**
+
 ```bash
 npm run test:coverage
 # ERROR: Coverage threshold not met!
 ```
 
 ### `exclude` (w coverage)
+
 **Co to robi:** Te pliki nie liczą się do pokrycia
 **Co wykluczamy:**
+
 - `src/test/` - same testy
 - `**/*.config.*` - pliki konfiguracyjne (vitest.config.ts, itp.)
 - `src/db/database.types.ts` - auto-generowane przez Supabase
@@ -77,19 +91,22 @@ npm run test:coverage
 ## 🎨 Aliasy ścieżek
 
 ### `alias: { "@": "./src" }`
+
 **Co to robi:** Możesz pisać `@/components` zamiast `../../../components`
 **Przykład:**
+
 ```typescript
 // Zamiast:
-import { Button } from '../../../components/ui/Button';
+import { Button } from "../../../components/ui/Button";
 
 // Piszesz:
-import { Button } from '@/components/ui/Button';
+import { Button } from "@/components/ui/Button";
 ```
 
 ## 🚀 Jak używać
 
 ### Podstawowe komendy
+
 ```bash
 # Watch mode (rekomendowane podczas developmentu)
 npm run test
@@ -106,6 +123,7 @@ npm run test:coverage
 ```
 
 ### Pierwszy test
+
 ```typescript
 // src/components/Button.test.tsx
 import { render, screen } from '@testing-library/react';
@@ -120,6 +138,7 @@ describe('Button', () => {
 ```
 
 ### Uruchom:
+
 ```bash
 npm run test
 # Vitest automatycznie znajdzie *.test.tsx
@@ -128,22 +147,28 @@ npm run test
 ## 💡 Tipsy dla początkujących
 
 ### 1. Używaj Watch Mode
+
 ```bash
 npm run test
 ```
+
 Vitest automatycznie uruchomi testy gdy zapiszesz plik!
 
 ### 2. Używaj UI Mode do debugowania
+
 ```bash
 npm run test:ui
 ```
+
 Zobaczysz GUI z:
+
 - Listą wszystkich testów
 - Wynikami w czasie rzeczywistym
 - Stack traces
 - Console logi
 
 ### 3. Filtruj testy podczas developmentu
+
 ```bash
 # Tylko testy z "Button" w nazwie
 npm run test -- Button
@@ -153,9 +178,11 @@ npm run test -- src/components/Button.test.tsx
 ```
 
 ### 4. Nie martw się o coverage na początku
+
 Zacznij od pisania testów, coverage przyjdzie z czasem.
 
 Kiedy sprawdzać coverage:
+
 - Przed mergem do main
 - Co jakiś czas, żeby zobaczyć progress
 
@@ -168,6 +195,7 @@ npm run test:coverage
 ## 🎓 Dobre praktyki
 
 ### 1. Jeden plik testowy na komponent
+
 ```
 src/
   components/
@@ -176,38 +204,42 @@ src/
 ```
 
 ### 2. Grupuj testy w describe
+
 ```typescript
-describe('Button', () => {
-  describe('when disabled', () => {
-    it('should not call onClick', () => {
+describe("Button", () => {
+  describe("when disabled", () => {
+    it("should not call onClick", () => {
       // test
     });
   });
 
-  describe('when enabled', () => {
-    it('should call onClick', () => {
+  describe("when enabled", () => {
+    it("should call onClick", () => {
       // test
     });
   });
 });
 ```
 
 ### 3. Używaj opisowych nazw testów
+
 ```typescript
 // ❌ Źle
-it('works', () => {});
+it("works", () => {});
 
 // ✅ Dobrze
-it('should call onClick when button is clicked', () => {});
+it("should call onClick when button is clicked", () => {});
 ```
 
 ### 4. Najpierw funkcjonalność, potem coverage
+
 Nie pisz testów tylko po to żeby mieć 100% coverage.
 Pisz testy które testują **zachowanie** Twojej aplikacji.
 
 ## ⚙️ Kiedy zmienić ustawienia
 
 ### Masz już stabilne testy i chcesz wyższych standardów?
+
 ```typescript
 thresholds: {
   lines: 80,
@@ -218,15 +250,19 @@ thresholds: {
 ```
 
 ### Potrzebujesz LCOV dla CI/CD?
+
 ```typescript
 reporter: ["text", "html", "lcov"],
 ```
+
 LCOV używa się do integracji z narzędziami jak Codecov.
 
 ### Chcesz testować bez DOM (czyste funkcje)?
+
 ```typescript
 environment: "node",  // Zamiast "jsdom"
 ```
+
 Szybsze, ale nie zadziała dla komponentów React!
 
 ## ❓ FAQ
@@ -268,4 +304,3 @@ A: Nie! 60-80% to dobry cel. 100% często oznacza testowanie implementacji zamia
 ### Wszystko inne jest OK! ✅
 
 Config był już dobry, tylko lekko zoptymalizowany dla początkującego.
-