Lantern

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.

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ü.

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.

Ama asıl kabus, geliştirme ortamında yaşanıyordu. Her projeyi ayağa kaldırmak için farklı portlar belirlemek gerekiyordu — auth :8080'de, marketplace :8081'de, storefront :3000'de. Bir hafta sonra geri döndüğünde hangi servis hangi portta çalışıyordu? Kimse hatırlamıyordu. Üstüne bir de canlıdaki kimlik doğrulama sunucusu — redirect_url tanımlamak, localhost:8080 ile üretim IDP'sini eşleştirmeye çalışmak, token'ın neden geçersiz döndüğünü anlamaya uğraşırken saatler harcamak. Her servisin kendi .env dosyası, kendi port haritası, kendi bağımlılık grafiği vardı. Bir tanesini değiştirdiğinde diğer ikisinin de güncellenmesi gerekiyordu — ama bunu sana söyleyen bir mekanizma yoktu.

İhtiyaç açıktı: tüm servisleri tek bir ortamda, tek bir komutla ayağa kaldırıp, port çakışmalarını ortadan kaldıran, kimlik doğrulamayı yerelde çözen ve entegrasyon noktalarını otomatik olarak doğrulayan bir altyapı.

İ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 bir araya getirdim. Makefile tabanlı basit komutlarla tüm süreç yönetilebilir hale geldi.

Kritik bir tasarım kararı daha vardı: altyapı hem CI pipeline'ı hem de geliştirici masaüstü için aynı şekilde çalışmalıydı. Bir geliştirici make test-smoke ile hızlı bir sağlık kontrolü yapabilir, make test-e2e ile tam E2E süitini çalıştırabilir, ya da make test-cli ile sadece CLI testlerini hedefleyebilir. Aynı Makefile, aynı Docker Compose, aynı seed scriptleri — yerel makinede çalışan her şey CI'da da çalışır.

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 — partner paneli, admin arayüzü, geliştirici CLI aracı, SQL profiling servisi, e-posta test sunucusu — her biri mevcut altyapıya minimum eforla entegre edildi.

Her entegrasyon projesi kendi engellerini getirir. İşte Lantern'in yolculuğunda karşılaşılan temel zorluklar ve onlara bulunan çözümler:

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 19 bileşenden oluşuyor: tema yönetimi, storefront migration akışı, visual regression ekran görüntüleri, geliştirici yaşam döngüsü akışı, fork lineage takibi, admin inceleme akışı ve daha fazlası. Servis sağlık durumu izleme, JUnit XML sonuçları, drill-down hata detayları — hepsi sıfır harici veritabanı bağımlılığı ile. SQLite, Nitro'nun yerel depolama katmanı olarak çalışır.

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. Visual regression testleri sayesinde tema değişikliklerinin görsel etkisi piksel düzeyinde doğrulanır. E-posta akışları Mailpit ile uçtan uca test edilir. Yeni bir servis eklendiğinde, mevcut altyapı onu doğal olarak absorbe eder.

Altyapı yaşayan bir organizma — durağan değil. .dev domain'lerine geçiş ve Playwright ile tarayıcı tabanlı testler tamamlandı. Şimdi sırada: CI/CD pipeline entegrasyonu ile her commit'te otomatik E2E doğrulaması, performans profiling raporlarının dashboard'a entegrasyonu ve storefront migration süreçlerinin tam otomasyonu. Her yeni ekleme, Lantern'in asıl amacını güçlendiriyor: karmaşıklığı basitliğe dönüştürmek.