@hd-agent-kit/cli 1.3.1 → 1.4.0

package/templates/skills/performance-check/SKILL.md

@@ -15,7 +15,7 @@ description: Analyze bundle size, render performance, and Core Web Vitals with s
 
 - **Ölçmeden optimize etme.** Önce darboğazı tespit et, sonra çöz.
 - **Premature optimization is the root of all evil.** Gerçek sorunlara odaklan.
-- **Core Web Vitals odaklı ol.** LCP, INP, CLS metrikleri öncelikli.
+- **Proje tipine göre öncelik belirle:** Frontend → Core Web Vitals; Backend → response time + DB; CLI → startup time + memory.
 - **Bundle size'ı her zaman göz önünde bulundur.** Her KB önemli, özellikle mobilde.
 
 ---
@@ -23,16 +23,21 @@ description: Analyze bundle size, render performance, and Core Web Vitals with s
 ## Kullanım Formatları
 
 ```
-/performance-check                         ← Tüm proje analizi
+/performance-check                         ← Tüm proje analizi (proje tipine göre uyarlanır)
 /performance-check src/pages/Home.tsx      ← Belirli sayfa/component
 /performance-check bundle                  ← Sadece bundle analizi
-/performance-check render                  ← Sadece render performansı
+/performance-check render                  ← Sadece render performansı (frontend)
+/performance-check api                     ← Sadece API/backend performansı
+/performance-check db                      ← Sadece veritabanı sorgu analizi
 ```
 
 ---
 
 ## Analiz Kategorileri
 
+> **Proje tipine göre uygula:** Frontend/Fullstack → Kategori 1-5; Backend API → Kategori 6-7; CLI/Araç → Kategori 8.
+> Karma projeler (fullstack) için tüm ilgili kategorileri uygula.
+
 ### Kategori 1: Bundle Analizi
 
 Projenin bundle yapısını incele:
@@ -198,24 +203,120 @@ Component render davranışını analiz et:
 
 ---
 
+### Kategori 6: Backend & API Performansı *(Standalone API / Fullstack backend için)*
+
+```
+⚡ Backend Performansı:
+
+1. Response Time Analizi:
+   ├── Yavaş endpoint'ler tespit edilmiş mi? (>200ms P95)
+   ├── Logging/monitoring var mı? (pino, morgan, Datadog vs.)
+   ├── Timeout değerleri uygun mu?
+   └── Async işlemler non-blocking mı?
+
+2. Veritabanı Sorgu Optimizasyonu:
+   ├── N+1 sorgu riski: [var/yok — ORM include/join kullanımı]
+   ├── Index kullanımı: [sorgu planları incelendi mi?]
+   ├── Bağlantı havuzu (connection pool): [yapılandırılmış mı?]
+   ├── Büyük veri setleri cursor/stream ile mi işleniyor?
+   └── Migration'lar optimize mi? (büyük tablo değişimleri)
+
+3. Caching Stratejisi:
+   ├── HTTP Cache-Control header'ları: [var/yok]
+   ├── Uygulama seviyesi cache (Redis, in-memory): [var/yok]
+   ├── Cache invalidation stratejisi: [var/yok]
+   └── Duplicate API çağrılarını önleme: [var/yok]
+
+4. Eşzamanlılık & Ölçeklenebilirlik:
+   ├── Rate limiting: [var/yok — hangi endpoint'lerde]
+   ├── Concurrency limitler uygun mu?
+   ├── CPU-yoğun işlemler worker_threads ile mi?
+   └── Horizontal scaling engelleyen state var mı? (in-memory session vs.)
+```
+
+**Kontrol Listesi:**
+
+| # | Kontrol | Durum | Etki |
+|---|---------|-------|------|
+| 1 | N+1 sorgu riski var mı? | ✅/❌ | Yüksek |
+| 2 | DB connection pool yapılandırılmış mı? | ✅/❌ | Yüksek |
+| 3 | Yavaş sorgular için index var mı? | ✅/❌ | Yüksek |
+| 4 | Rate limiting aktif mi? | ✅/❌ | Orta |
+| 5 | Caching katmanı var mı? | ✅/❌ | Orta |
+| 6 | CPU-yoğun işlemler event loop'u bloke ediyor mu? | ✅/❌ | Yüksek |
+| 7 | Response time izleniyor mu? | ✅/❌ | Orta |
+
+---
+
+### Kategori 7: Bellek & Process Yönetimi *(Node.js projeleri için)*
+
+```
+🧠 Bellek & Process:
+
+1. Bellek Kullanımı:
+   ├── Bellek sızıntısı riski: [event listener temizleme, büyük closure'lar]
+   ├── Stream kullanımı: [büyük dosyalar için createReadStream/createWriteStream]
+   ├── --max-old-space-size limiti: [tanımlı mı?]
+   └── Buffer kullanımı: [gereksiz kopyalama var mı?]
+
+2. Event Loop Sağlığı:
+   ├── Senkron bloke eden işlemler: [var/yok — fs.readFileSync, execSync gibi]
+   ├── setInterval/setTimeout temizleme: [clearInterval/clearTimeout çağrılıyor mu?]
+   └── Uzun süren hesaplamalar: [ana thread'i bloke ediyor mu?]
+
+3. Graceful Shutdown:
+   ├── SIGTERM/SIGINT handler'ları: [var/yok]
+   ├── Açık DB bağlantıları kapatılıyor mu?
+   └── In-flight request'ler tamamlanıyor mu?
+```
+
+---
+
+### Kategori 8: CLI & Build Araçları Performansı *(CLI / Tooling projeleri için)*
+
+```
+🛠️ CLI Performansı:
+
+1. Startup Time:
+   ├── Gereksiz require/import var mı? (lazy load edilebilir mi?)
+   ├── Ağır modüller conditional import ile yükleniyor mu?
+   └── --version ve --help hızlı mı? (<100ms)
+
+2. Dosya İşleme Performansı:
+   ├── Büyük dosyalar stream ile işleniyor mu?
+   ├── Paralel işlemler Promise.all ile mi?
+   └── Gereksiz dosya okuma/yazma döngüsü var mı?
+
+3. Bellek Kullanımı:
+   ├── Büyük JSON/veri setleri bellekte tutuluyor mu?
+   └── İşlem sonrası geçici dosyalar temizleniyor mu?
+```
+
+---
+
 ## Puanlama Sistemi
 
 Her kategori için 0-100 puan ver:
 
 ```
-📊 Performans Raporu:
-
-┌──────────────────────┬───────┬──────────┐
-│ Kategori             │ Puan  │ Seviye   │
-├──────────────────────┼───────┼──────────┤
-│ Bundle Size          │ XX/100│ 🟢/🟡/🔴│
-│ Render Performansı   │ XX/100│ 🟢/🟡/🔴│
-│ Core Web Vitals      │ XX/100│ 🟢/🟡/🔴│
-│ Network & Caching    │ XX/100│ 🟢/🟡/🔴│
-│ Asset Optimizasyonu  │ XX/100│ 🟢/🟡/🔴│
-├──────────────────────┼───────┼──────────┤
-│ GENEL                │ XX/100│ 🟢/🟡/🔴│
-└──────────────────────┴───────┴──────────┘
+📊 Performans Raporu: [Proje Adı] — [Frontend / Backend / CLI]
+
+Sadece proje tipine uygun kategorileri ekle:
+
+┌──────────────────────────────┬───────┬──────────┐
+│ Kategori                     │ Puan  │ Seviye   │
+├──────────────────────────────┼───────┼──────────┤
+│ Bundle Size           (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+│ Render Performansı    (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+│ Core Web Vitals       (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+│ Network & Caching            │ XX/100│ 🟢/🟡/🔴│  ← Tüm tipler
+│ Asset Optimizasyonu   (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+│ Backend & API Perf    (BE)   │ XX/100│ 🟢/🟡/🔴│  ← Backend/Fullstack
+│ Bellek & Process      (BE)   │ XX/100│ 🟢/🟡/🔴│  ← Backend/CLI
+│ CLI Performansı       (CLI)  │ XX/100│ 🟢/🟡/🔴│  ← CLI/Tooling
+├──────────────────────────────┼───────┼──────────┤
+│ GENEL                        │ XX/100│ 🟢/🟡/🔴│
+└──────────────────────────────┴───────┴──────────┘
 
 🟢 90-100: Mükemmel
 🟡 60-89: İyileştirme alanı var

package/templates/skills/security-scan/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: security-scan
-description: Run dependency audit, detect XSS/CSRF risks, check env variables, and report security issues
+description: Run dependency audit, detect OWASP Top 10 risks, check auth/env/injection vulnerabilities, and report security issues for any project type
 ---
 
 # /security-scan — Güvenlik Tarama Skill'i
 
 > **Tetikleyici:** `/security-scan`
-> **Amaç:** Dependency audit, XSS/CSRF risk tespiti, env variable kontrolü ve güvenlik best practice'lerine uyum raporu oluşturmak.
+> **Amaç:** Dependency audit, OWASP Top 10 risk tespiti, auth güvenliği, env variable kontrolü ve proje tipine göre güvenlik analizi.
 > **Çıktı:** Kategorize edilmiş güvenlik raporu + düzeltme önerileri
 
 ---
@@ -219,7 +219,55 @@ description: Run dependency audit, detect XSS/CSRF risks, check env variables, a
    └── Rate limiting: [var/yok]
 ```
 
-### Kategori 7: Frontend-Specific Güvenlik
+### Kategori 7: Backend-Specific Güvenlik *(Standalone API / Fullstack backend için)*
+
+```
+🖥️ Backend Güvenlik:
+
+1. Path Traversal & Dosya Sistemi:
+   ├── Kullanıcı girdisi dosya yolunda kullanılıyor mu?: [var/yok]
+   ├── path.resolve() + allowlist kontrolü: [var/yok]
+   ├── Upload dosya adları sanitize ediliyor mu?: [var/yok]
+   └── Sembolik link takibi engelleniyor mu?: [var/yok]
+
+2. Mass Assignment:
+   ├── ORM modellerine doğrudan req.body aktarılıyor mu?: [var/yok — risk]
+   ├── Whitelist (allowedFields) kontrolü: [var/yok]
+   ├── Hassas alanlar (role, isAdmin) otomatik güncellenebiliyor mu?: [var/yok]
+   └── Zod/validation şeması ile alan kısıtlaması: [var/yok]
+
+3. Server-Side Request Forgery (SSRF):
+   ├── Kullanıcı girdisinden URL oluşturuluyor mu?: [var/yok]
+   ├── İzin verilen domain allowlist'i: [var/yok]
+   ├── Internal IP/localhost erişimi engelleniyor mu?: [var/yok]
+   └── Metadata endpoint'lerine erişim (cloud): [var/yok]
+
+4. Process & Komut Enjeksiyonu:
+   ├── child_process / exec'e kullanıcı girdisi geçiyor mu?: [var/yok — KRİTİK]
+   ├── Shell=true ile spawn kullanımı: [var/yok — riskli]
+   ├── eval() / new Function() kullanımı: [var/yok]
+   └── Template engine injection riski: [var/yok]
+
+5. Güvenli Yanıt Başlıkları:
+   ├── helmet.js veya manuel header'lar: [var/yok]
+   ├── X-Powered-By gizlenmiş mi?: [Evet/Hayır]
+   ├── Server header gizlenmiş mi?: [Evet/Hayır]
+   └── Error response'larda stack trace sızıyor mu?: [var/yok — KRİTİK]
+```
+
+**Kontrol Listesi:**
+
+| # | Kontrol | Durum | Etki |
+|---|---------|-------|------|
+| 1 | Path traversal koruması var mı? | ✅/❌ | Kritik |
+| 2 | Mass assignment koruması var mı? | ✅/❌ | Yüksek |
+| 3 | SSRF koruması var mı? | ✅/❌ | Yüksek |
+| 4 | exec/shell'e kullanıcı girdisi geçiyor mu? | ✅/❌ | Kritik |
+| 5 | Stack trace production'da gizleniyor mu? | ✅/❌ | Orta |
+
+---
+
+### Kategori 8: Frontend-Specific Güvenlik *(Frontend / Fullstack UI için)*
 
 ```
 🖥️ Frontend Güvenlik:
@@ -250,19 +298,22 @@ description: Run dependency audit, detect XSS/CSRF risks, check env variables, a
 ```
 🔒 Güvenlik Raporu:
 
-┌──────────────────────────┬───────┬──────────┐
-│ Kategori                 │ Puan  │ Seviye   │
-├──────────────────────────┼───────┼──────────┤
-│ Dependency Güvenliği     │ XX/100│ 🟢/🟡/🔴│
-│ XSS Koruması             │ XX/100│ 🟢/🟡/🔴│
-│ CSRF & Request Security  │ XX/100│ 🟢/🟡/🔴│
-│ Auth & Authorization     │ XX/100│ 🟢/🟡/🔴│
-│ Environment & Secrets    │ XX/100│ 🟢/🟡/🔴│
-│ Input Validation         │ XX/100│ 🟢/🟡/🔴│
-│ Frontend Security        │ XX/100│ 🟢/🟡/🔴│
-├──────────────────────────┼───────┼──────────┤
-│ GENEL                    │ XX/100│ 🟢/🟡/🔴│
-└──────────────────────────┴───────┴──────────┘
+Sadece proje tipine uygun kategorileri tabloya ekle:
+
+┌─────────────────────────────────┬───────┬──────────┐
+│ Kategori                        │ Puan  │ Seviye   │
+├─────────────────────────────────┼───────┼──────────┤
+│ Dependency Güvenliği            │ XX/100│ 🟢/🟡/🔴│  ← Tüm tipler
+│ XSS Koruması             (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+│ CSRF & Request Security  (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+│ Auth & Authorization            │ XX/100│ 🟢/🟡/🔴│  ← Tüm tipler
+│ Environment & Secrets           │ XX/100│ 🟢/🟡/🔴│  ← Tüm tipler
+│ Input Validation                │ XX/100│ 🟢/🟡/🔴│  ← Tüm tipler
+│ Backend Security         (BE)   │ XX/100│ 🟢/🟡/🔴│  ← Backend/Fullstack
+│ Frontend Security        (FE)   │ XX/100│ 🟢/🟡/🔴│  ← Frontend/Fullstack
+├─────────────────────────────────┼───────┼──────────┤
+│ GENEL                           │ XX/100│ 🟢/🟡/🔴│
+└─────────────────────────────────┴───────┴──────────┘
 
 🟢 90-100: Güvenli
 🟡 60-89: İyileştirme gerekli

package/templates/skills/write-tests/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: write-tests
-description: Generate comprehensive test files for components, hooks, and utilities following project conventions
+description: Generate comprehensive test files for components, hooks, utilities, API endpoints, services, and CLI tools following project conventions
 ---
 
 # /write-tests — Test Yazma Skill'i
 
 > **Tetikleyici:** `/write-tests [dosya/modül]`
-> **Amaç:** Belirtilen component, hook veya utility için kapsamlı test dosyası üretmek.
+> **Amaç:** Belirtilen component, hook, utility, API endpoint, service veya CLI araç için kapsamlı test dosyası üretmek.
 > **Çıktı:** Proje convention'ına uygun test dosyası
 
 ---
 
 ## Temel İlkeler
 
-- **Kullanıcı davranışını test et, implementation detail'leri değil.** Testing Library felsefesi.
+- **Davranışı test et, implementasyonu değil.** Neyin yapıldığını test et, nasıl yapıldığını değil.
 - **Her test bağımsız (isolated) olmalı.** Testler arası paylaşılan state olmamalı.
 - **Mock'ları minimum tut.** Gerçek modülleri mümkün olduğunca kullan.
 - **Test piramidini uygula.** Çok unit test, az integration test, minimal E2E test.
@@ -43,13 +43,13 @@ Hedef dosyayı oku ve şunları tespit et:
 ```
 📋 Test Hedefi Analizi:
 ├── Hedef dosya: [dosya yolu]
-├── Dosya tipi: [component / hook / util / service / page]
-├── Export'lar: [fonksiyon/component listesi]
-├── Bağımlılıklar: [import edilen modüller]
+├── Dosya tipi: [component / hook / util / service / route / middleware / controller / CLI command]
+├── Export'lar: [fonksiyon/class/component listesi]
+├── Bağımlılıklar: [import edilen modüller — mock edilmesi gerekenler]
 ├── Props/Parametreler: [tip bilgileri]
-├── Side effect'ler: [API çağrısı, localStorage, timer vs.]
+├── Side effect'ler: [API çağrısı, DB sorgusu, dosya I/O, timer, env var vs.]
 ├── Mevcut test: [var/yok, dosya yolu]
-└── Test runner: [Vitest / Jest / projeden tespit et]
+└── Test runner: [Vitest / Jest / node:test — projeden tespit et]
 ```
 
 ### Adım 2: Proje Test Convention Tespiti
@@ -71,9 +71,9 @@ Projede mevcut testleri inceleyerek convention belirle:
 
 ### Adım 3: Test Senaryoları Planlama
 
-Her dosya tipi için farklı senaryo stratejisi:
+Her dosya tipi için farklı senaryo stratejisi. **Proje tipine göre uygun bölümü uygula.**
 
-#### Component Test Senaryoları
+#### Component Test Senaryoları *(Frontend / Fullstack UI için)*
 ```
 📝 Test Planı — [ComponentName]:
 
@@ -114,7 +114,7 @@ Her dosya tipi için farklı senaryo stratejisi:
    □ Screen reader uyumlu mu?
 ```
 
-#### Hook Test Senaryoları
+#### Hook Test Senaryoları *(Frontend / Fullstack UI için)*
 ```
 📝 Test Planı — [useHookName]:
 
@@ -144,7 +144,8 @@ Her dosya tipi için farklı senaryo stratejisi:
    □ Invalid parametre geçilmesi
 ```
 
-#### Utility/Service Test Senaryoları
+#### Utility/Service Test Senaryoları *(Tüm proje tipleri için)*
+
 ```
 📝 Test Planı — [functionName]:
 
@@ -167,6 +168,183 @@ Her dosya tipi için farklı senaryo stratejisi:
    □ Return tipi doğru çıkarılıyor mu?
 ```
 
+#### API Endpoint Test Senaryoları *(Backend / Fullstack API için)*
+
+```
+📝 Test Planı — [METHOD /path]:
+
+1. Başarılı İstek (Happy Path):
+   □ Geçerli payload ile doğru response kodu (200/201/204)
+   □ Response body şeması doğru mu?
+   □ Response header'ları doğru mu? (Content-Type, Location vs.)
+
+2. Kimlik Doğrulama & Yetkilendirme:
+   □ Token/session olmadan → 401 Unauthorized
+   □ Yetersiz yetki ile → 403 Forbidden
+   □ Geçerli token ile → beklenen response
+
+3. Validasyon Hataları:
+   □ Eksik zorunlu alan → 400 Bad Request + açıklayıcı hata
+   □ Hatalı veri tipi → 400 + alan bazlı hata mesajı
+   □ Sınır değer ihlali (çok uzun string, negatif sayı) → 400
+
+4. Kaynak Bulunamadı:
+   □ Var olmayan ID ile → 404 Not Found
+   □ Silinmiş kaynak → 404 veya 410 Gone
+
+5. Çakışma Durumları:
+   □ Duplicate kayıt → 409 Conflict
+   □ Eşzamanlı güncelleme → 409 veya optimistic lock
+
+6. Hata Senaryoları:
+   □ DB bağlantısı kesilirse → 503 Service Unavailable (mock ile)
+   □ Harici servis yanıt vermezse → timeout ve fallback davranışı
+
+7. Edge Case'ler:
+   □ Büyük payload → boyut limiti kontrolü
+   □ SQL/NoSQL injection girişimi → sanitize edilmiş mi?
+   □ Rate limit aşımı → 429 Too Many Requests
+```
+
+**Supertest ile endpoint testi:**
+
+```typescript
+import request from 'supertest';
+import { app } from '../app';
+import { db } from '../db/client';
+
+describe('POST /api/users', () => {
+  beforeEach(async () => {
+    await db.user.deleteMany(); // test izolasyonu
+  });
+
+  it('should create a user and return 201', async () => {
+    const res = await request(app)
+      .post('/api/users')
+      .send({ name: 'Test User', email: 'test@example.com' })
+      .expect(201);
+
+    expect(res.body).toMatchObject({
+      id: expect.any(String),
+      name: 'Test User',
+      email: 'test@example.com',
+    });
+  });
+
+  it('should return 400 for missing email', async () => {
+    const res = await request(app)
+      .post('/api/users')
+      .send({ name: 'Test User' })
+      .expect(400);
+
+    expect(res.body.code).toBe('VALIDATION_ERROR');
+    expect(res.body.details).toHaveProperty('email');
+  });
+
+  it('should return 401 without auth token', async () => {
+    await request(app)
+      .post('/api/users')
+      .send({ name: 'Test', email: 'a@b.com' })
+      .expect(401);
+  });
+});
+```
+
+#### Middleware Test Senaryoları *(Backend için)*
+
+```
+📝 Test Planı — [middlewareName]:
+
+1. Geçerli istek → next() çağrılıyor mu?
+2. Geçersiz/yetersiz veri → next() çağrılmadan hata response'u
+3. Request nesnesini doğru şekilde zenginleştiriyor mu? (req.user vs.)
+4. Loglama/metrik side effect'leri doğru tetikleniyor mu?
+5. Asenkron hata → next(err) ile iletiliyor mu?
+```
+
+```typescript
+import { authMiddleware } from '../middleware/auth';
+
+describe('authMiddleware', () => {
+  const mockNext = vi.fn();
+  const mockRes = { status: vi.fn().mockReturnThis(), json: vi.fn() } as any;
+
+  it('should call next() with valid token', async () => {
+    const req = { headers: { authorization: 'Bearer valid-token' } } as any;
+    vi.mocked(verifyToken).mockResolvedValue({ userId: '123' });
+
+    await authMiddleware(req, mockRes, mockNext);
+
+    expect(req.user).toEqual({ userId: '123' });
+    expect(mockNext).toHaveBeenCalledWith(); // hatasız
+  });
+
+  it('should return 401 without token', async () => {
+    const req = { headers: {} } as any;
+
+    await authMiddleware(req, mockRes, mockNext);
+
+    expect(mockRes.status).toHaveBeenCalledWith(401);
+    expect(mockNext).not.toHaveBeenCalled();
+  });
+});
+```
+
+#### CLI Araç Test Senaryoları *(CLI / Tooling için)*
+
+```
+📝 Test Planı — [komut adı]:
+
+1. Happy Path:
+   □ Beklenen argümanlarla → beklenen çıktı ve exit code 0
+   □ Oluşturulan dosyalar doğru içeriğe sahip mi?
+   □ Yan etkiler (dosya oluşturma, git komutu) gerçekleşiyor mu?
+
+2. Flag Davranışı:
+   □ --force flag'i ile onay sorulmadan devam ediyor mu?
+   □ --dry-run ile gerçek değişiklik yapılmıyor mu?
+   □ --help ile yardım metni gösteriliyor mu?
+
+3. Hata Durumları:
+   □ Bilinmeyen komut → açıklayıcı hata + exit code 1
+   □ Dosya zaten varken (--force olmadan) → onay soruluyor mu?
+   □ İzin hatası (erişilemeyen dizin) → anlamlı hata mesajı
+
+4. Cross-Platform:
+   □ Windows ve Unix yol separator'ları doğru işleniyor mu?
+```
+
+```typescript
+import { execSync } from 'child_process';
+import * as fs from 'fs';
+import * as path from 'path';
+import * as os from 'os';
+
+describe('cli init --force', () => {
+  let testDir: string;
+
+  beforeEach(() => {
+    testDir = fs.mkdtempSync(path.join(os.tmpdir(), 'cli-test-'));
+  });
+
+  afterEach(() => {
+    fs.rmSync(testDir, { recursive: true, force: true });
+  });
+
+  it('should create AGENTS.md in target directory', () => {
+    execSync(`node bin/cli.js init --force`, { cwd: testDir });
+
+    expect(fs.existsSync(path.join(testDir, 'AGENTS.md'))).toBe(true);
+  });
+
+  it('should exit with code 1 for unknown command', () => {
+    expect(() => {
+      execSync(`node bin/cli.js unknown-cmd`, { stdio: 'pipe' });
+    }).toThrow();
+  });
+});
+```
+
 ### Adım 4: Test Dosyası Oluşturma
 
 Test planını onaylandıktan sonra, proje convention'ına uygun test dosyası yaz: