i.
Test Yazma Deneyimi: E2E'ye Giden Yol
E2E test altyapısı kurmak, bir gecede ortaya çıkan bir fikir değildi. Bu noktaya gelmeden önce yıllarca farklı seviyelerde test yazmak gerekti. Unit testlerle başlayan yolculuk, integration testlerle derinleşti ve sonunda uçtan uca bakış açısını zorunlu kılan bir noktaya geldi.
Unit testler bana tek bir fonksiyonun doğruluğunu garanti etmeyi öğretti: saf girdi-çıktı, mock'lanmış bağımlılıklar, hızlı geri bildirim döngüsü. Integration testler ise bunun ötesine geçti — bir servisin veritabanıyla, cache ile, üçüncü parti API'lerle gerçekten doğru çalışıp çalışmadığını gösterdi. Ama her ikisinin de ortak bir kör noktası vardı:
Tek bir servis perspektifinden bakıyorlardı. Servis A'nın unit testleri geçer, Servis B'nin integration testleri yeşildir — ama A'dan B'ye bir API çağrısı sessizce kırılmış olabilir. Bunu yakalayan ne unit test, ne integration test. Bunu yakalayan E2E perspektifi.
E2E Çapraz servis akış doğrulaması
Integration Servis + veritabanı + harici API
Unit Tek fonksiyon, izole doğrulama
Bu deneyim bana şunu öğretti: her test seviyesi bir öncekinin kör noktasını aydınlatır. Unit testler yazmadan integration testleri anlamak zor; integration testleri yazmadan E2E'nin neden gerekli olduğunu kavramak neredeyse imkansız. Her seviye, bir sonrakinin temelini oluşturuyor. Lantern, bu biriken deneyimin doğal bir ürünü.
"Testler sadece hata yakalamak için değil — sistemi anlamak için yazılır. Her seviye, farklı bir perspektif açar."
ii.
Neden Böyle Bir Şeye İhtiyaç Duyuldu?
Hikaye basit başladı: birbirinden bağımsız geliştirilmiş üç mikroservis, bir noktada birlikte çalışmak zorundaydı. Bir kimlik doğrulama servisi, bir marketplace API'si ve bir storefront. Her biri kendi reposunda, kendi veritabanında, kendi deploy döngüsünde yaşıyordu.
Sorun şuydu: her servis tek başına kusursuz çalışıyordu, ama birlikte çalıştıklarında kırılgandılar. Bir servisteki küçük bir API değişikliği, diğer iki serviste sessizce sorunlara yol açabiliyordu. Bunu fark etmenin tek yolu, birinin manuel olarak tüm akışı baştan sona test etmesiydi — ki bu her seferinde saatler süren, hataya açık bir süreçti.
İhtiyaç açıktı: tüm servisleri tek bir ortamda ayağa kaldırıp, entegrasyon noktalarını otomatik olarak doğrulayacak bir altyapı.
iii.
Yaklaşım: API-First E2E
İlk kararım kritikti: tarayıcı testleri yerine API-first yaklaşımı benimsemek. Neden? Çünkü entegrasyon sorunlarının büyük çoğunluğu servisler arası HTTP çağrılarında ortaya çıkıyordu, kullanıcı arayüzünde değil. API-first yaklaşım, tarayıcı karmaşıklığı olmadan entegrasyon doğrulamasının %80'ini sunuyordu.
Docker Compose ile tüm servisleri — paylaşımlı MySQL, Redis, nginx ve OAuth sunucusu dahil — tek bir ağda orkestre ettim. Makefile tabanlı basit komutlarla tüm süreç yönetilebilir hale geldi.
iv.
Ölçeklenme: 3'ten 6'ya
Altyapı başlangıçta 3 servis için tasarlanmıştı ama gerçek değerini, yeni servisler eklendiğinde kanıtladı. Ekosistem büyüdükçe — bir partner paneli, yeni bir admin arayüzü, bir geliştirici CLI aracı — her biri mevcut altyapıya minimum eforla entegre edildi.
Başlangıç
3 servis — Storefront, Marketplace API ve OAuth sunucusu. Temel entegrasyon testleri: kimlik doğrulama akışı, tema yayınlama, tema kurulumu.
Büyüme
+2 servis — Partner paneli ve admin arayüzü eklendi. Yeni test senaryoları: iş ortağı onay akışları, yönetici inceleme süreçleri. Docker Compose'a yeni servis eklemek, tek bir blok yazmak kadar basitti.
Mevcut Durum
6+ servis — Geliştirici CLI aracı ve sandbox ortamı planlamada. SSL sertifika yönetimi, çoklu domain desteği ve tarayıcı testleri altyapıya ekleniyor. Mimari, yeni servisleri doğal olarak absorbe edebilecek şekilde tasarlandı.
"Mimariyi bir kez doğru kurarsan, ölçekleme sadece bir konfigürasyon meselesi haline gelir."
v.
Çözülen Zorluklar
Her entegrasyon projesi kendi engellerini getirir. İşte Lantern'in yolculuğunda karşılaşılan temel zorluklar ve onlara bulunan çözümler:
Servisler Arası Entegrasyon
→
Tek Docker ağı, koordineli veritabanı besleme, paylaşımlı servis keşfi
OAuth Karmaşıklığı
→
Programatik client_credentials akışı, otomatik token yönetimi
Test İzolasyonu
→
Ayrı test veritabanları, her çalıştırmada temiz besleme, sıfır kirlilik
Anlık Görünürlük
→
SSE ile gerçek zamanlı akış paneli, canlı konsol ve ilerleme takibi
SSL & Domain Yönetimi
→
mkcert ile yerel güvenilir sertifikalar, çoklu domain için tek nginx reverse proxy
vi.
Canlı Dashboard
Testleri çalıştırmak yetmez — sonuçları anlamlı bir biçimde sunmak gerekir. Nuxt 4 ile geliştirdiğim dashboard, Server-Sent Events ile test ilerlemesini gerçek zamanlı olarak aktarır. Her test çalıştırması SQLite'a kaydedilir; trend grafikleri, başarı oranları ve geçmiş karşılaştırmaları tek bir ekranda görülebilir.
Dashboard aynı zamanda 6 servisin sağlık durumunu izler, JUnit XML sonuçlarını detaylı bir tabloda sunar ve hata detaylarını drill-down ile incelemeye olanak tanır. Sıfır harici veritabanı bağımlılığı — SQLite, Nitro'nun yerel depolama katmanı olarak çalışır.
viii.
Etki
27/27
gereksinim karşılandı
Lantern, manuel test süreçlerini ortadan kaldırarak entegrasyon güvenini kalıcı hale getirdi. Tek komutla tüm servisler ayağa kalkar, veritabanları hazırlanır, testler çalışır ve sonuçlar canlı olarak izlenir. Yeni bir servis eklendiğinde, mevcut altyapı onu doğal olarak absorbe eder — mimari bu ölçeklenebilirlik için tasarlandı.
ix.
Sonraki Adımlar
Altyapı yaşayan bir organizma — durağan değil. Şu anda üzerinde çalışılan konular: .dev domain'lerine geçiş ile tam SSL desteği, tarayıcı tabanlı E2E testlerin etkinleştirilmesi, ve geliştirici CLI aracı için sandbox ortamı. Her yeni ekleme, Lantern'in asıl amacını güçlendiriyor: karmaşıklığı basitliğe dönüştürmek.
"Önce çalıştır, sonra güzelleştir."