paint-brush
Mükemmel Yalıtılmış Uçtan Uca Ortam Oluşturmaile@marcinwosinek
511 okumalar
511 okumalar

Mükemmel Yalıtılmış Uçtan Uca Ortam Oluşturma

ile Marcin Wosinek5m2023/04/12
Read on Terminal Reader
Read this story w/o Javascript

Çok uzun; Okumak

Kesintili testler kodunuzla ilgisi olmayan nedenlerden dolayı başarısız olan testlerdir. Aşırı durumlarda, hatalı testler ekibinize E2E sonuçlarını göz ardı etmeyi öğretecektir. Bu, kalite kontrolünü (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.
featured image - Mükemmel Yalıtılmış Uçtan Uca Ortam Oluşturma
Marcin Wosinek HackerNoon profile picture

Kararlı uçtan uca (E2E) testler için dışarıdan mümkün olduğunca izole edilmiş bir ortama ihtiyacımız var.

Pullanmayı Azaltın

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:


  • Farklı test işleri tarafından paylaşılan arka uçta saklanan durum ve


  • Üzerinde kontrol sahibi olmadığınız harici hizmetler.


Bu yaklaşımdan etkilenmeyen başka pullanma kaynakları da vardır:


  • Asıl sorun rastgele ortaya çıkan uygulamada veya


  • Uygulamadaki sorunlara, E2E'nin uygulamayla etkileşime girdiği doğal olmayan hız neden oluyor.

Alternatif

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:


  • Test içindeki veri değişikliklerini geri döndürmeye çalışsak da bazı test başarısızlıkları arkasında beklenmedik değişiklikler bırakıyordu.


  • Paralel işler çarpışıyordu. Farklı test işleri aynı durumları değiştiriyordu ve bu da çoğu zaman işlerden birinin başarısız olmasına neden oluyordu.

Her Şeyi Dockerlaştırın

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:


  • Doğru işletim sistemi (veya daha doğrusu doğru Linux dağıtımı),


  • görüntü işleme kitaplıkları vb. gibi sistem bağımlılıkları ve


  • Dil tercümanlarının (Python, Node vb.) veya veritabanı sunucularının doğru sürümü.

Veri tabanı

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 uç

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.

Başlangıç aşaması

Dağıtım stratejinize bağlı olarak aşağıdakilerden birini yapabilirsiniz:


  1. Oluşturduğunuz kapsayıcıları ön uç yapısının bir parçası olarak kullanın.


  2. 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'da İş Hizmetleri

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.

İş İçi İzolasyon için Geçici Verileri Değerlendirin

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 Testten Sonra Temizleme

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:


  • Yalnızca bir test çalıştırdığınızda, testin karşılaştığı durum, dosyadaki tüm testleri çalıştırdığınızdaki durumdan farklı olmaz.


  • Veritabanının önceki çalıştırmalardan etkilenmemesi için aynı testi yerel olarak tekrar tekrar çalıştırdığınızda

Sahte Harici Hizmet

Hizmetleri bir konteynere taşımanın bir seçenek olmadığı durumlar vardır. Örneğin:


  • Uygulamanın doğrudan veya bazı arka uç proxy'leri aracılığıyla kullandığı harici sunucular varsa veya


  • Teknik sorunlar nedeniyle bir konteyner içinde çalıştırılması mümkün olmayan sunucularınız var.


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 .

Öğrenmeye Devam Edin

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.