GitHub Actions'ta API E-posta Testleri: Sözleşme Yaklaşımı

E-posta bildirimlerini test eden CI pipeline'ları genellikle egzotik hatalardan değil, sıradan tasarım kusurlarından çöker: paylaşılan gelen kutuları, yalnızca konu metnine bakan zayıf assertion'lar ve API tetiklemeli akışları gereksiz yere tarayıcı üzerinden doğrulama alışkanlığı. Bu durum yeşil geçen pipeline'ların bile şablon regresyonlarını gözden kaçırmasına yol açıyor.

Yazar, her workflow çalışmasının dört şeyi kanıtlaması gerektiğini öneriyor: isteğin beklenen domain event'ini üretmesi, o event için tam olarak bir eşleşen mesajın gelmesi, mesaj içeriğinin doğru actor/resource bağlamını taşıması ve hataların tek bir run id ile açıklanabilmesi. Bunu sağlamak için job başında run-scoped bir inbox id oluşturulup API çağrısına ve mailbox okuyucusuna aynı id'nin geçirilmesi öneriliyor.

Örnek GitHub Actions workflow'u, RUN_INBOX_ID gibi bir ortam değişkenini adım adım taşıyarak paralel job'larda triage'ı hızlandırıyor. Assertion script'i bilinçli olarak dar tutuluyor: mesaj sayısı tam bir olmalı, alıcı run kapsamıyla eşleşmeli, beklenen link/token bulunmalı ve eski şablon parçaları olmamalı. Böylece tarayıcı tabanlı ağır e2e testlerine ihtiyaç kalmadan, API sınırına yakın, hızlı ve gürültüsüz bir doğrulama katmanı kuruluyor.

Mühendisler için önemi açık: paylaşılan inbox'lar ve UI'a bağımlı e-posta testleri flaky CI'ın klasik kaynaklarından biri. Run-scoped inbox yaklaşımı küçük bir değişiklik olsa da, hem geri bildirim süresini kısaltıyor hem de false-positive rerun'ları azaltıyor.