Kararlı uçtan uca (E2E) testler için dışarıdan mümkün olduğunca izole edilmiş bir ortama ihtiyacımız var.
Kesintili testler, kodunuzla ilgisi olmayan nedenlerden dolayı başarısız olan testlerdir. Uygulamanın doğruluğu için güvenilir bir kontrol olarak E2E'nin kullanılmasını zorlaştırırlar. Aşırı durumlarda, hatalı testler ekibinize E2E sonuçlarını göz ardı etmeyi öğretecektir. Bu, kalite kontrolü (QA) otomatikleştirme çabasını ortadan kaldırabilir.
Burada sunulan yaklaşım, test çalıştırmalarınızdaki iki büyük potansiyel sorun kaynağını ele almaktadır:
Bu yaklaşımdan etkilenmeyen başka pullanma kaynakları da vardır:
Ekibim ve ben testlerimi özel bir arka uç konteynerinde çalıştırmadan önce üretim dışı sunucularımızdan birini kullandık. Bu yaklaşım, E2E çözümümüzün deneme aşamasında gayet iyiydi.
Sadece birkaç test olduğunda, zaten test sonuçlarını karar vermek için kullanamıyorduk.
Ancak daha fazla test eklemeye devam ettikçe ve yürütme süreleri uzadıkça bu yaklaşım çökmeye başladı. Ana konular aşağıdaki gibiydi:
Bu soruna bir çözüm, her test işi için ayrı bir arka uç sunucusu ve veritabanı tahsis etmekti. Docker olmasaydı bu yaklaşım çok zorlayıcı olurdu.
Docker kapsayıcıları, bir uygulamanın çalışması için ihtiyaç duyduğu her şeyi içeren kapalı bir ortam oluşturmak için mükemmel bir araçtır:
Testiniz için öngörülebilir test verileriyle birlikte gelen özel bir veritabanı kapsayıcısı hazırlayabilirsiniz. Bu şekilde, her E2E uygulamasında başlangıç noktasını tam olarak yeniden oluşturabilecek ve testlerinizi daha kararlı hale getirebileceksiniz.
Test veritabanının sürümlendirilmesi amacıyla Docker görüntünüz için farklı etiketler kullanabilirsiniz. Aynı test veritabanı bir geliştirme ortamında da kullanılabilir. Geliştirme aşamasındaki manuel testler için, otomatik testlere benzer örnek varlıklara ihtiyacınız vardır.
Arka ucunuzu dağıtmak için Docker'ı zaten kullandıysanız, aynı görüntüyü E2E'nizi çalıştırmak için yeniden kullanmak oldukça kolay olacaktır. Ekibimde, bir arka ucu kapsayıcılar olarak dağıtıyoruz ve ortam değişkenleri olarak veritabanı URL'lerini ve kimlik bilgilerini sağlıyoruz.
Aynı konteyner sürümü, üretimde dağıtılabilir veya testleri çalıştırmak için sürekli entegrasyonda (CI) kullanılabilir; her ortam, veritabanına bağlanmak için doğru değerleri sağlar.
Dağıtım stratejinize bağlı olarak aşağıdakilerden birini yapabilirsiniz:
Oluşturduğunuz kapsayıcıları ön uç yapısının bir parçası olarak kullanın.
Derlenmiş dosyaları alın ve bunların testler için HTTP aracılığıyla kullanılabildiğinden emin olun.
Bizim durumumuzda seçenek 2'yi kullanıyoruz: uygulamayı statik dosyalar olarak dağıtıyoruz, bu nedenle E2E iş çalıştırmaları sırasında oluşturulan dosyaları sunmak için özel bir kapsayıcı oluşturduk.
GitLab'ı CI'mızı çalıştırmak için bir platform olarak kullanıyoruz. GitLab'daki her iş, seçtiğiniz bir görüntünün bulunduğu bir konteynerin içinde çalıştırılır. Ana konteynerin yanı sıra hizmetleri de tanımlayabilirsiniz: Testlerinizin yanında çalışan ek konteynerler. Yapılandırma şu kadar kolaydır:
<job-name>: services: - name: <image> alias: <container-url>
Kullanılabilir seçenekler Docker Compose'daki seçeneklere benzer ancak daha sınırlıdır.
GitLab yapılandırmasındaki bir "yapma", test çalıştırması sırasında hizmetlerin birbirine erişmesine izin vermek istiyorsanız FF_NETWORK_PER_BUILD
değişkenini 1'e ayarlamaktır.
Bir noktada tüm testleri paralel olarak tek bir işte yürütüyorduk. O zamanlar izolasyonun daha da güçlü hale getirilmesi gerekiyordu; her test aynı arka ucu ve veritabanını kullanıyordu.
Bu soruna geçici bir çözüm bulmak için testlerimizi, öncelikle testlerin before
bölümüne enjekte ettiğimiz rastgele verilere dayanacak şekilde yükselttik. Bu, testlerin diğer başlıklarda meydana gelen diğer değişikliklerden etkilenmeden çalışmasına izin verdi.
Bu yaklaşım ilk başta biraz yanıltıcı olabilir, ancak koşullarınıza bağlı olarak mantıklı olabilir.
Her test işi için yeni bir veritabanı başlatsak da testlerimizin uygulamayı buldukları durumda bırakmasını sağlamaya çalışıyoruz. Belki de testleri ortak bir ortamda yürüttüğümüz dönemden kalma bir parçadır.
Artık çok önemli değil ancak aşağıdaki durumlarda test geliştirme sırasında hala yardımcı olabilir:
Hizmetleri bir konteynere taşımanın bir seçenek olmadığı durumlar vardır. Örneğin:
Her iki durumda da test çalıştırmalarını izole etmek için bu hizmetlere giden istekleri taklit edebilirsiniz. Bu, öngörülemeyen harici hizmetlerin test sonuçlarınızı etkilemesini önleyecektir. Bu yaklaşımın bir dezavantajı, testlerinizin uygulamalarınızın çalıştığı bağlamdan kopmasıdır.
Taklitler mevcut olduğunda, testleriniz bu hizmetlerdeki değişikliklerin uygulamanızı etkilediği durumları yakalamayacaktır .
Test etme veya programlamayla ilgili diğer konular hakkında daha fazla bilgi edinmek istiyorsanız, ilgili içeriği yayınladığımda güncellemeleri almak için buradan kaydolabilirsiniz.