🏷️ B2 · Model/Entity: Bug sınıfı, enum, alan tipleri

B2 · Model/Entity: Bug sınıfı, enum: Model sınıfı, API'nin **sözlüğüdür**: bir "bug"ın ne demek olduğunu — hangi alanları var, her alan ne tipte, hangi değerler geçerli — tek yer

Model sınıfı, API'nin **sözlüğüdür**: bir "bug"ın ne demek olduğunu — hangi alanları var, her alan ne tipte, hangi değerler geçerli — tek yerde tanımlar. `severity` için serbest metin yerine bir **enum** (LOW/MEDIUM/HIGH/CRITICAL) kullanmak, "sadece bu dört kelime kabul edilir" demektir. Peki neden `String severity` bırakmıyoruz, esnek olmaz mı? Çünkü esneklik burada bir tuzaktır: `String` olsa biri `"critical"`, biri `"Critical"`, biri `"acil"` yazar ve raporların, filtrelerin, önceliklendirmenin hepsi bozulur — enum, geçersiz değeri daha kapıda (deserialization'da) reddeder. Java'da bunun karşılığı zaten `enum` tipidir; tip sistemi geçersiz durumu derleme/parse zamanında imkânsız kılar (Core Java'daki "make illegal states unrepresentable" ilkesi). QA açısından model, test verisi üretmenin haritasıdır: hangi alan zorunlu, hangi enum değerleri geçerli, hangi format (email, ISO tarih) bekleniyor — negatif testlerini (geçersiz enum, hatalı tarih) buradan türetirsin.

Bug Modeli ve Enum'lar

**🐞 Defect Doğum Anı — `severity` enum yerine `String` bırakılırsa** **Kod:** `private String severity;` (enum DEĞİL). **Ne olur:** `POST /api/v1/bugs { "severity": "acil" }` request'i 400 yerine 201 döner; veritabanına geçersiz bir öncelik yazılır. Bir gün sonra "kritik bugları getir" filtresi (`severity == "CRITICAL"`) bu kaydı ISKALAR — kritik bir bug rapor ekranında hiç görünmez. **Neden sinsi:** Kayıt başarıyla oluşur (201), UI onu listeler, hiçbir hata yoktur. Sorun ancak bir filtre/rapor çalışınca, hem de sessizce ortaya çıkar: yanlış yazılmış öncelik bir "hayalet kayıt" olur. **Tester nerede yakalar:** Negatif testte — geçersiz bir `severity` değeri (`"acil"`, `"critical"`, `"5"`) gönderip 400 beklerken 201 alınca. Enum olsaydı sunucu bu değeri deserialization'da reddederdi.

🎬 Enum mu String mi? Geçersiz Önceliğin Hayalet Kaydı

Bir request geçersiz bir öncelikle geliyor: `severity: "acil"` — bu dört geçerli değerden biri değil. Ne olacak, modele bağlı.

Model enum ise: deserialization bir kapı gibi çalışır, "acil" tanınmaz ve request 400 ile REDDEDİLİR. Geçersiz veri hiç içeri girmez.

Ama model String ise kapı YOKTUR: "acil" olduğu gibi kabul edilir ve veritabanına yazılır. Request 201 döner — sorun görünmez.

Ertesi gün — "kritik bugları getir" filtresi `severity == "CRITICAL"` arar; "acil" kaydını ISKALAR. Kritik bir bug rapor ekranında yoktur.

Ders — Enum, geçersiz durumu kapıda imkânsız kılar. Tester bunu negatif testle avlar: geçersiz enum gönder, 400 bekle. String modeli bu kapıyı kaldırır.

Model, Test Verisinin Haritasıdır

Zorunlu alanları bul…

Modelden title'ın zorunlu olduğunu görürsün → "title'sız POST" bir negatif test doğar.

Enum sınırlarını bul…

severity'nin 4 geçerli değeri var → "geçersiz enum" (acil, 5, boş) testleri buradan türer.