Kesintili otomasyon testleri, QA mühendisleri için bir bela olabilir, belirsizlik yaratabilir ve test paketlerinin güvenilirliğini zayıflatabilir. SDET ve QA Otomasyon mentoru olarak deneyimlerimden yararlanan bu makale, düzensizliği yenmek için pratik tavsiyeler sunuyor. Her ne kadar JavaScript ve Oyun Yazarı örnekleri sunsam da, bu evrensel ipuçları her dilde ve çerçevede uygulanabilir olup sağlam ve güvenilir otomasyon testleri yazmanıza yardımcı olur. Gelin hemen dalalım ve testlerinizin sağlam durduğundan emin olalım.  1. Örtülü bekleme yöntemlerinden kaçının  Bazen, test senaryonuza devam etmek için öğelerin DOM'da görünmesini veya uygulamanızın belirli bir duruma ulaşmasını beklemeniz gereken durumlarla karşılaşırsınız. Playwright'ın otomatik bekleme özellikleri gibi modern, akıllı otomasyon çerçevelerinde bile özel bekleme yöntemlerini uygulamanız gereken durumlar olacaktır. Örneğin, metin alanları ve onay düğmesi olan bir senaryo düşünün. Belirli sunucu tarafı davranışları nedeniyle, onay düğmesi yalnızca formun doldurulmasından yaklaşık beş saniye sonra görünür hale gelir. Bu gibi durumlarda, iki test adımı arasına beş saniyelik örtülü bir bekleme eklemenin cazibesine direnmek çok önemlidir.   textField.fill('Some text') waitForTime(5000) confirmationButton.click()  Bunun yerine akıllı bir yaklaşım kullanın ve tam durumu bekleyin. Bu, bir miktar yüklemeden sonra görünen metin öğesi veya geçerli adım başarıyla tamamlandıktan sonra kaybolan bir yükleyici döndürme öğesi olabilir. Bir sonraki test adımına hazır olup olmadığınızı kontrol edebilirsiniz.   button.click() waitFor(textField.isVisible()) textField.fill()  Elbette akıllıca kontrol edemediğiniz bir şeyi beklemeniz gereken durumlar vardır. Bu tür yerlere yorum eklemenizi, hatta neden açıklamasını bekleme yöntemlerinize bir parametre olarak veya buna benzer bir şey olarak eklemenizi öneririm:   waitForTime(5000, {reason: "For unstable server processed something..."}  Bunu kullanmanın ek bir faydası da, bu tür açıklamaları saklayabileceğiniz test raporlarıdır, böylece başkası için veya hatta gelecekte sizin için neyin ve neden bu kadar beş saniye beklediğinizin açık olması sağlanır.   waitForTime(5000, {reason: "For unstable server processed something..."} button.click() waitFor(textField.isVisible()) textField.fill()  2. Elemanları seçmek için sağlam ve güvenilir konumlayıcılar kullanın  Konum belirleyiciler otomasyon testinin çok önemli bir parçasıdır ve herkes bunu bilir. Ancak bu basit gerçeğe rağmen birçok otomasyon mühendisi kararlılıktan yararlanıyor ve testlerinde buna benzer bir şey kullanıyor.   //*[@id="editor_7"]/section/div[2]/div/h3[2]  Bu çok saçma bir yaklaşım çünkü DOM yapısı o kadar da statik değil; Bazı farklı ekipler bazen bunu değiştirebilir ve bu, testleriniz başarısız olduktan sonra yapılabilir. Bu nedenle, sağlam konumlayıcıları kullanın. Bu arada, XPath ile ilgili hikaye okumama hoş geldiniz.   https://hackernoon.com/getting-your-way-around-with-common-xpath-methods?embedable=true  3. Testleri birbirinden bağımsız yapın  Test paketini tek bir iş parçacığında birden fazla testle çalıştırırken, her testin bağımsız olmasını sağlamak çok önemlidir. Bu, bir sonraki testin beklenmeyen koşullar nedeniyle başarısız olmaması için ilk testin sistemi orijinal durumuna döndürmesi gerektiği anlamına gelir. Örneğin, testlerinizden biri LocalStorage'da depolanan kullanıcı ayarlarını değiştiriyorsa, ilk test çalıştırmalarından sonra Kullanıcı Ayarları için LocalStorage girişini temizlemek iyi bir yaklaşımdır. Bu, ikinci testin varsayılan kullanıcı ayarlarıyla yürütülmesini sağlar. Ayrıca, her yeni testin aynı başlangıç koşullarıyla başlaması için sayfayı varsayılan giriş sayfasına sıfırlamak ve çerezleri ve veritabanı girişlerini temizlemek gibi işlemleri de düşünebilirsiniz.  Örneğin, Playwright'ta bunu başarmak için beforeAll(), beforeEach(), afterAll() ve afterEach() ek açıklamalarını kullanabilirsiniz.  Birkaç test içeren bir sonraki test paketini kontrol edin. Birincisi kullanıcının görünüm ayarlarını değiştirmek, ikincisi ise varsayılan görünümü kontrol etmektir.   test.describe('Test suite', () => { test('TC101 - update appearance settings to dark', async ({page}) => { await user.goTo(views.settings); await user.setAppearance(scheme.dark); }); test('TC102 - check if default appearance is light', async ({page}) => { await user.goTo(views.settings); await user.checkAppearance(scheme.light); }); });  Böyle bir test paketi paralel olarak çalışırsa her şey sorunsuz ilerleyecektir. Ancak bu testler tek tek yapılırsa, biri diğerini etkilediği için başarısız bir testle karşı karşıya kalabilirsiniz. İlk test, görünümü açıktan karanlığa değiştirdi. İkinci test mevcut görünümün açık olup olmadığını kontrol eder. Ancak ilk test varsayılan görünümü zaten değiştirdiği için başarısız olacaktır.  Böyle bir sorunu çözmek için, her testten sonra çalıştırılan afterEach() kancasını ekledim. Bu durumda, varsayılan görünüme gidecek ve kullanıcının görünümünü Yerel Depolamadan kaldırarak temizleyecektir.   test.afterEach(async ({ page }) => { await user.localStorage(appearanceSettings).clear() await user.goTo(views.home) }); test.describe('Test suite', () => { test('TC101 - update appearance settings to dark', async ({page}) => { await user.goto(views.settings); await user.setAppearance(scheme.dark); }); test('TC102 - check if default appearance is light', async ({page}) => { await user.goTo(views.settings); await user.checkAppearance(scheme.light); }); });  Bu yaklaşımı kullanarak bu paketteki her test bağımsız olacaktır.  4. Otomatik yeniden denemeleri akıllıca kullanın  Hiç kimse hatalı testlerle karşılaşmaktan muaf değildir ve bu soruna yönelik popüler bir çözüm, yeniden denemelerin kullanılmasını içerir. Yeniden denemeleri CI/CD yapılandırma düzeyinde bile otomatik olarak gerçekleştirilecek şekilde yapılandırabilirsiniz. Örneğin, başarısız olan her test için maksimum yeniden deneme sayısını üç kez belirterek otomatik yeniden denemeler ayarlayabilirsiniz. Başlangıçta başarısız olan herhangi bir test, test yürütme döngüsü tamamlanana kadar üç defaya kadar yeniden denenecektir. Bunun avantajı, eğer testiniz biraz bozuksa, birkaç tekrar denemeden sonra geçebilmesidir.  Ancak olumsuz tarafı, başarısız olabilmesi ve bunun sonucunda fazladan çalışma süresi tüketimine yol açabilmesidir. Üstelik bu uygulama yanlışlıkla hatalı testlerin birikmesine yol açabilir, çünkü birçok test ikinci veya üçüncü denemede "geçmiş" gibi görünebilir ve bunları yanlışlıkla kararlı olarak etiketleyebilirsiniz. Bu nedenle, test projenizin tamamı için otomatik yeniden denemeleri genel olarak ayarlamanızı önermiyorum. Bunun yerine, testteki temel sorunları hemen çözemediğiniz durumlarda yeniden denemeleri seçici olarak kullanın.  Örneğin, 'filechooser' olayını kullanarak bazı dosyaları yüklemeniz gereken bir test senaryonuz olduğunu varsayalım. 'filechooser' olayı beklenirken <Timeout aşıldı> hatasını alıyorsunuz; bu, Playwright testinin bir 'filechooser' olayının gerçekleşmesini beklediğini ancak bekleme zaman aşımının daha uzun sürdüğünü gösterir.   async function uploadFile(page: Page, file) { const fileChooserPromise = page.waitForEvent('filechooser'); await clickOnElement(page, uploadButton); const fileChooser = await fileChooserPromise; await fileChooser.setFiles(file); }  Bunun nedeni, uygulamadaki beklenmeyen davranışlar veya yavaş ortam gibi çeşitli nedenlerden kaynaklanabilir. Rastgele bir davranış olduğu için düşünebileceğiniz ilk şey bu test için otomatik yeniden denemeyi kullanmaktır. Ancak testin tamamını yeniden denerseniz fazladan zaman kaybetme ve uploadFile() yöntemindeki ilk hatada aldığınız davranışın aynısını alma riskiyle karşı karşıya kalırsınız; dolayısıyla hata oluşursa testin tamamını yeniden denemenize gerek kalmaz.  Bunu yapmak için standart try…catch ifadesini kullanabilirsiniz.   async function uploadFile(page: Page, file) { const maxRetries = 3; let retryCount = 0; while (retryCount < maxRetries) { try { const fileChooserPromise = page.waitForEvent('filechooser'); await clickOnElement(page, uploadButton); const fileChooser = await fileChooserPromise; await fileChooser.setFiles(file); break; // Success, exit the loop } catch (error) { console.error(`Attempt ${retryCount + 1} failed: ${error}`); retryCount++; } } }  Böyle bir yaklaşım ekstra zaman kazandıracak ve testinizin daha az hatalı olmasını sağlayacaktır.  Son olarak, güvenilir otomasyon testlerine giden yol basittir. Yaygın zorlukları en aza indirebilir veya aktif olarak ele alabilir ve akıllı stratejiler uygulayabilirsiniz. Unutmayın, bu yolculuk devam ediyor ve kararlılıkla testleriniz daha güvenilir hale gelecektir. Pul pul dökülmeye elveda deyin ve istikrara hoş geldiniz. Kaliteye olan bağlılığınız projenin başarısını garanti eder. Mutlu testler!    da yayınlandı. Burada

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Kesintisiz Testlerin Dört Atlısı

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Görünmeyen Katmanlar: Kullanıcı Görüşmeleri Neden Yeri doldurulamaz bir Varlıktır?

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Görünmeyen Katmanlar: Kullanıcı Görüşmeleri Neden Yeri doldurulamaz bir Varlıktır?

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps