Kesintili Testler: Testlerde Yaşayan Bir Kabustan Kurtulmak

Bugünlerde çokça düşündüğüm bir masal var. Masal bana çocukken anlatılmıştı. Aesop tarafından "Kurt Ağlayan Çocuk" denir. Köyünün koyunlarını güden bir çocuk hakkındadır. Canı sıkılır ve bir kurdun sürüye saldırdığını, köylüleri yardıma çağırdığını iddia eder - sadece köylülerin bunun yanlış bir alarm olduğunu hayal kırıklığına uğratıp çocuğu rahat bırakmaları için. Daha sonra, bir kurt ortaya çıktığında ve çocuk yardım çağırdığında, köylüler bunun başka bir yanlış alarm olduğuna inanırlar ve kurtarmaya gelmezler ve koyunlar kurt tarafından yenir.

Hikayenin ahlaki en iyi yazarın kendisi tarafından özetlenir:

"Doğru söylese bile yalancıya inanılmaz."

Bir kurt koyunlara saldırır ve çocuk yardım için ağlar, ancak sayısız yalandan sonra artık kimse ona inanmaz. Bu ahlaki test için geçerli olabilir: Ezop'un hikayesi, denk geldiğim bir eşleştirme modeli için güzel bir alegori: herhangi bir değer sağlamayan lapa lapa testler.

Ön Uç Testi: Neden Rahatsız Edilir?

Günlerimin çoğu ön uç testleriyle geçiyor. Bu yüzden bu makaledeki kod örneklerinin çoğunlukla çalışmamda karşılaştığım ön uç testlerinden olması sizi şaşırtmamalı. Ancak çoğu durumda diğer dillere kolayca çevrilebilir ve diğer çerçevelere uygulanabilir. Bu nedenle, makalenin sizin için yararlı olacağını umuyorum - ne tür bir uzmanlığa sahip olursanız olun.

Ön uç testinin ne anlama geldiğini hatırlamakta fayda var. Özünde, ön uç testi, işlevselliği de dahil olmak üzere bir web uygulamasının kullanıcı arayüzünü test etmek için bir dizi uygulamadır.

Bir kalite güvence mühendisi olarak yola çıktığımda, piyasaya sürülmeden hemen önce bir kontrol listesinden sonsuz manuel testin acısını biliyorum. Bu nedenle, bir uygulamanın ardışık güncellemeler sırasında hatasız kalmasını sağlama amacına ek olarak, aslında bir insana ihtiyaç duymadığınız rutin görevlerin neden olduğu testlerin iş yükünü hafifletmeye çalıştım. Şimdi, bir geliştirici olarak, özellikle kullanıcılara ve iş arkadaşlarına doğrudan yardım etmeye çalışırken, konuyu hala alakalı buluyorum. Ve özellikle testlerle ilgili bize kabuslar yaşatan bir sorun var.

Kesintili Testlerin Bilimi

Kesintili test, aynı analiz her çalıştırıldığında aynı sonucu vermeyen testtir. Derleme yalnızca ara sıra başarısız olur: Bir kez geçer, başka bir zaman başarısız olur, bir dahaki sefere, yapıda herhangi bir değişiklik yapılmadan tekrar geçer.

Test kabuslarımı hatırladığımda, özellikle bir vaka geliyor aklıma. Bir UI testindeydi. Özel tarzda bir birleşik giriş kutusu oluşturduk (yani giriş alanı olan seçilebilir bir liste):

Bu birleşik giriş kutusu ile bir ürün arayabilir ve sonuçlardan bir veya daha fazlasını seçebilirsiniz. Birçok gün, bu test iyi gitti, ancak bir noktada işler değişti. Sürekli entegrasyon (CI) sistemimizdeki yaklaşık on yapıdan birinde, bu birleşik giriş kutusunda ürün arama ve seçme testi başarısız oldu.

Başarısızlığın ekran görüntüsü, aramanın başarılı olmasına rağmen sonuç listesinin filtrelenmediğini gösteriyor:

Bunun gibi kesintili bir test , sürekli dağıtım hattını engelleyerek özellik teslimini olması gerekenden daha yavaş hale getirebilir. Ayrıca, lapa lapa bir test sorunludur çünkü artık deterministik değildir - onu işe yaramaz hale getirir. Sonuçta, bir yalancıya güveneceğinizden daha fazla güvenemezsiniz.

Ek olarak, kesintili testlerin onarımı pahalıdır ve hata ayıklaması genellikle saatler hatta günler sürer. Uçtan uca testler düzensiz olmaya daha yatkın olsa da, bunları her türlü testte deneyimledim: birim testleri, işlevsel testler, uçtan uca testler ve aradaki her şey.

Kesintili testlerle ilgili bir diğer önemli sorun, biz geliştiricilere aşıladıkları tutumdur. Test otomasyonunda çalışmaya başladığımda, geliştiricilerin başarısız bir teste yanıt olarak şunu söylediğini sık sık duydum:

"Ahh, o yapı. Boş ver, tekrar başla. Eninde sonunda bir şekilde geçecek."

Bu benim için büyük bir kırmızı bayrak . Bana yapımdaki hatanın ciddiye alınmayacağını gösteriyor. Kesintili bir testin gerçek bir hata olmadığı, ilgilenilmeye ve hatta hata ayıklanmaya ihtiyaç duymadan "sadece" kesintili olduğu varsayımı vardır. Zaten sınav daha sonra tekrar geçecek, değil mi? Hayır! Böyle bir taahhüt birleştirilirse, en kötü durumda üründe yeni bir lapa lapa testi yapacağız.

nedenleri

Bu nedenle, lapa lapa testleri sorunludur. Onlar hakkında ne yapmalıyız? Sorunu biliyorsak, bir karşı strateji tasarlayabiliriz.

Günlük hayatta sık sık sebeplerle karşılaşırım. Testlerin kendilerinde bulunabilirler . Testler yetersiz yazılmış olabilir, yanlış varsayımlar içerebilir veya kötü uygulamalar içerebilir. Ancak, sadece bu değil. Kesintili testler çok daha kötü bir şeyin göstergesi olabilir.

İlerleyen bölümlerde, karşılaştığım en yaygın olanları gözden geçireceğiz.

1. Test Tarafı Nedenleri

İdeal bir dünyada, uygulamanızın ilk durumu bozulmamış ve %100 öngörülebilir olmalıdır. Gerçekte, testinizde kullandığınız kimliğin her zaman aynı olup olmayacağını asla bilemezsiniz.

Benim açımdan tek bir başarısızlığın iki örneğini inceleyelim. Bir numaralı hata, test fikstürlerimde bir kimlik kullanmaktı :

 { "id": "f1d2554b0ce847cd82f3ac9bd1c0dfca", "name": "Variant product", }

İki numaralı hata, bir UI testinde kullanmak için benzersiz bir seçici aramak ve "Tamam, bu kimlik benzersiz görünüyor. kullanacağım.”

 <!-- This is a text field I took from a project I worked on --> <input type="text" />

Ancak, testi başka bir kurulumda veya daha sonra CI'deki birkaç yapı üzerinde çalıştırırsam, bu testler başarısız olabilir. Uygulamamız, kimlikleri yeniden oluşturacak ve bunları derlemeler arasında değiştirecektir. Bu nedenle, olası ilk neden, sabit kodlanmış kimliklerde bulunur.

İkinci neden, rastgele (veya başka şekilde) oluşturulan demo verilerinden kaynaklanabilir . Elbette, bu "kusurun" haklı olduğunu düşünüyor olabilirsiniz - sonuçta, veri oluşturma rastgeledir - ancak bu verilerde hata ayıklamayı düşünün. Testlerin kendisinde mi yoksa demo verilerinde mi bir hata olduğunu görmek çok zor olabilir.

Sıradaki, defalarca mücadele ettiğim bir test tarafı nedeni: çapraz bağımlılıklarla testler . Bazı testler bağımsız olarak veya rastgele bir sırayla çalışamayabilir, bu da sorunludur. Ayrıca, önceki testler sonraki testleri etkileyebilir. Bu senaryolar, yan etkiler ortaya çıkararak lapa lapa testlere neden olabilir.

Ancak, testlerin zorlu varsayımlarla ilgili olduğunu unutmayın. Varsayımlarınız başlangıçta kusurluysa ne olur? Bunları sık sık yaşadım, en sevdiğim şey zamanla ilgili hatalı varsayımlar.

Bir örnek, özellikle UI testlerinde hatalı bekleme sürelerinin kullanılmasıdır - örneğin, sabit bekleme süreleri kullanılarak. Aşağıdaki satır bir Nightwatch.js testinden alınmıştır.

 // Please never do that unless you have a very good reason! // Waits for 1 second browser.pause(1000);

Bir başka yanlış varsayım, zamanın kendisiyle ilgilidir. Bir keresinde lapa lapa bir PHPUnit testinin yalnızca gece derlemelerimizde başarısız olduğunu keşfettim. Biraz hata ayıklamadan sonra, suçlunun dün ile bugün arasındaki zaman kayması olduğunu buldum. Bir başka iyi örnek de saat dilimlerinden kaynaklanan arızalardır.

Yanlış varsayımlar burada bitmiyor. Verilerin sırası hakkında da yanlış varsayımlara sahip olabiliriz. Para birimi listesi gibi bilgiler içeren birden çok giriş içeren bir ızgara veya liste hayal edin:

İlk giriş bilgisi olan “Çek korunası” para birimi ile çalışmak istiyoruz. Uygulamanızın, testiniz her yürütüldüğünde, bu veri parçasını her zaman ilk giriş olarak yerleştireceğinden emin misiniz? Bazı durumlarda ilk giriş “Euro” veya başka bir para birimi olabilir mi?

Verilerinizin ihtiyaç duyduğunuz sırayla geleceğini varsaymayın. Sabit kodlanmış kimliklere benzer şekilde, uygulamanın tasarımına bağlı olarak yapılar arasında bir sıra değişebilir.

2. Çevre Yönlü Nedenler

Bir sonraki neden kategorisi, testlerinizin dışındaki her şeyle ilgilidir. Spesifik olarak, testlerin yürütüldüğü ortamdan, testlerinizin dışındaki CI ve liman işçisi ile ilgili bağımlılıklardan bahsediyoruz - en azından testçi olarak rolünüzde zorlukla etkileyebileceğiniz tüm bu şeyler.

Ortam tarafında yaygın bir neden kaynak sızıntılarıdır : Genellikle bu, yük altındaki bir uygulamadır ve değişen yükleme sürelerine veya beklenmeyen davranışlara neden olur. Büyük testler, çok fazla bellek tüketerek kolayca sızıntılara neden olabilir. Diğer bir yaygın sorun ise temizlik eksikliğidir .

Bağımlılıklar arasındaki uyumsuzluk bana özellikle kabuslar veriyor. UI testi için Nightwatch.js ile çalışırken bir kabus oldu. Nightwatch.js, elbette Chrome'a ​​bağlı olan WebDriver'ı kullanır. Chrome bir güncellemeyle öne çıktığında uyumlulukla ilgili bir sorun vardı: Chrome, WebDriver ve Nightwatch.js artık birlikte çalışmıyordu ve bu da derlemelerimizin zaman zaman başarısız olmasına neden oluyordu.

Bağımlılıklardan bahsetmişken : Eksik izinler veya npm'nin kapalı olması gibi herhangi bir npm sorununa onurlu bir söz verilir. Bunların hepsini CI'yi gözlemlerken yaşadım.

UI testlerinde çevresel sorunlardan kaynaklanan hatalar söz konusu olduğunda, bunların çalışması için tüm uygulama yığınına ihtiyacınız olduğunu unutmayın. Ne kadar çok şey dahil olursa , hata olasılığı o kadar artar. Bu nedenle JavaScript testleri, büyük miktarda kodu kapsadıkları için web geliştirmede stabilize edilmesi en zor testlerdir.

3. Ürün Taraflı Nedenler

Son fakat en az değil, bu üçüncü alan hakkında gerçekten dikkatli olmalıyız - gerçek böceklerin olduğu bir alan. Kesintilerin ürün taraflı nedenlerinden bahsediyorum. En iyi bilinen örneklerden biri, bir uygulamadaki yarış koşullarıdır . Bu olduğunda, hatanın testte değil, üründe düzeltilmesi gerekir! Testi veya ortamı düzeltmeye çalışmanın bu durumda hiçbir faydası olmayacaktır.

Pullanmayla Mücadele Yolları

Kesintiye neden olan üç neden belirledik. Karşı stratejimizi bunun üzerine kurabiliriz! Kesintili testlerle karşılaştığınızda bu üç nedeni göz önünde bulundurarak zaten çok şey kazanmış olacaksınız. Ne arayacağınızı ve testleri nasıl iyileştireceğinizi zaten bileceksiniz. Ancak buna ek olarak, testler tasarlamamıza, yazmamıza ve hata ayıklamamıza yardımcı olacak bazı stratejiler var ve bunları ilerleyen bölümlerde birlikte inceleyeceğiz.

Ekibinize Odaklanın

Takımınız tartışmasız en önemli faktördür . İlk adım olarak, lapa lapa testlerle ilgili bir sorununuz olduğunu kabul edin. Tüm ekibin bağlılığını almak çok önemlidir! Ardından, ekip olarak lapa lapa testlerle nasıl başa çıkacağınıza karar vermeniz gerekir.

Teknolojide çalıştığım yıllar boyunca, ekiplerin kesintilere karşı kullandığı dört stratejiyle karşılaştım:

1. Hiçbir şey yapmayın ve lapa lapa test sonucunu kabul edin.
   Tabii ki, bu strateji hiç bir çözüm değil. Test, artık ona güvenemeyeceğiniz için hiçbir değer vermeyecektir - kusurları kabul etseniz bile. Bu yüzden bunu oldukça hızlı bir şekilde atlayabiliriz.
2. Testi geçene kadar tekrar deneyin.
   Bu strateji, kariyerimin başlangıcında yaygındı ve daha önce bahsettiğim tepkiyle sonuçlandı. Testler geçene kadar yeniden denendiğinde bir miktar kabul vardı. Bu strateji hata ayıklama gerektirmez, ancak tembeldir. Sorunun belirtilerini gizlemenin yanı sıra, test takımınızı daha da yavaşlatacak ve bu da çözümün geçerliliğini yitirmesine neden olacaktır. Ancak, bu kuralın bazı istisnaları olabilir ve bunları daha sonra açıklayacağım.
3. Sil ve testi unut.
   Bu kendi kendini açıklayıcı: Test takımınızı daha fazla rahatsız etmemek için lapa lapa testi silmeniz yeterlidir. Elbette, size para kazandıracak çünkü artık testi hata ayıklamanıza ve düzeltmenize gerek kalmayacak. Ancak, biraz test kapsamını kaybetme ve olası hata düzeltmelerini kaybetme pahasına gelir. Testin bir nedeni var! Testi silerek haberciyi vurmayın.
4. Karantinaya alın ve düzeltin.
   Bu strateji ile en çok başarıyı elde ettim. Bu durumda, testi geçici olarak atlarız ve test paketinin bize sürekli olarak bir testin atlandığını hatırlatmasını sağlarız. Düzeltmenin gözden kaçmadığından emin olmak için bir sonraki sprint için bir bilet planlayacağız. Bot hatırlatıcıları da iyi çalışır. Kesintiye neden olan sorun giderildiğinde, testi tekrar entegre edeceğiz (yani atlamayı kaldıracağız). Ne yazık ki, geçici olarak kapsamı kaybedeceğiz, ancak bir düzeltme ile geri gelecek, bu yüzden bu uzun sürmeyecek.

Bu stratejiler, iş akışı düzeyinde test sorunlarıyla başa çıkmamıza yardımcı oluyor ve bunlarla karşılaşan tek kişi ben değilim. Sam Saffron da makalesinde benzer bir sonuca varıyor. Ancak günlük işlerimizde bize sınırlı bir ölçüde yardımcı oluyorlar. Peki, önümüze böyle bir görev geldiğinde nasıl ilerleyeceğiz?

Testleri İzole Edin

Test senaryolarınızı ve yapınızı planlarken, bağımsız veya rastgele bir sırada çalıştırılabilmesi için testlerinizi her zaman diğer testlerden ayrı tutun. En önemli adım, testler arasında temiz bir kurulumu geri yüklemektir . Ayrıca, yalnızca test etmek istediğiniz iş akışını test edin ve yalnızca testin kendisi için sahte veriler oluşturun. Bu kısayolun bir başka avantajı da test performansını artıracak olmasıdır. Bu noktaları takip ederseniz, diğer testlerden veya arta kalan verilerden hiçbir yan etki çıkmaz.

Aşağıdaki örnek, bir e-ticaret platformunun UI testlerinden alınmıştır ve müşterinin mağazanın vitrininde oturum açmasıyla ilgilidir. (Test, Cypress çerçevesi kullanılarak JavaScript ile yazılmıştır.)

 // File: customer-login.spec.js let customer = {}; beforeEach(() => { // Set application to clean state cy.setInitialState() .then(() => { // Create test data for the test specifically return cy.setFixture('customer'); }) }):

İlk adım, uygulamayı temiz bir kuruluma sıfırlamaktır. Sıfırlamanın her durumda gerçekleştirildiğinden emin olmak için beforeEach yaşam döngüsü kancasındaki ilk adım olarak yapılır. Daha sonra, test verileri özellikle test için oluşturulur - bu test senaryosu için özel bir komutla bir müşteri oluşturulur. Ardından, test etmek istediğimiz tek iş akışıyla başlayabiliriz: müşterinin oturum açması.

Test Yapısını Daha Fazla Optimize Edin

Test yapımızı daha kararlı hale getirmek için başka küçük değişiklikler yapabiliriz. Birincisi oldukça basit: Daha küçük testlerle başlayın. Daha önce de belirtildiği gibi, bir testte ne kadar çok yaparsanız, o kadar çok yanlış gidebilir. Testleri olabildiğince basit tutun ve her birinde çok fazla mantıktan kaçının.

Bir veri sırasını varsaymamak söz konusu olduğunda (örneğin, UI testinde bir listedeki girişlerin sırasını ele alırken), herhangi bir siparişten bağımsız çalışacak bir test tasarlayabiliriz. İçinde bilgi bulunan ızgara örneğini geri getirmek için, sözde seçiciler veya siparişe güçlü bir bağımlılığı olan diğer CSS'leri kullanmayacağız. nth-child(3) seçicisi yerine, sıranın önemli olmadığı metin veya başka şeyler kullanabiliriz. Örneğin, "Bu tablodaki bu tek metin dizesine sahip öğeyi bana bul" gibi bir iddia kullanabiliriz.

Beklemek! Test Yeniden Denemeleri Bazen Tamam mı?

Testleri yeniden denemek tartışmalı bir konudur ve haklı olarak öyle. Test başarılı olana kadar körü körüne yeniden denenirse, hala bir anti-kalıp olarak düşünüyorum. Ancak önemli bir istisna vardır: Hataları kontrol edemediğinizde, yeniden denemek son çare olabilir (örneğin, hataları harici bağımlılıklardan hariç tutmak için). Bu durumda, hatanın kaynağını etkileyemeyiz. Ancak bunu yaparken çok dikkatli olun: Bir testi yeniden denerken çatlaklara karşı kör olmayın ve bir test atlandığında size hatırlatmak için bildirimleri kullanın.

Aşağıdaki örnek, GitLab ile CI'mizde kullandığım örnektir. Diğer ortamlar, yeniden denemeleri gerçekleştirmek için farklı sözdizimlerine sahip olabilir, ancak bu size bir tat vermelidir:

 test: script: rspec retry: max: 2 when: runner_system_failure

Bu örnekte, iş başarısız olursa kaç tane yeniden deneme yapılması gerektiğini yapılandırıyoruz. İlginç olan, koşucu sisteminde bir hata varsa yeniden deneme olasılığıdır (örneğin, iş kurulumu başarısız oldu). Yalnızca liman işçisi kurulumunda bir şey başarısız olursa işimizi yeniden denemeyi seçiyoruz.

Bunun tetiklendiğinde tüm işi yeniden deneyeceğini unutmayın. Yalnızca hatalı testi yeniden denemek istiyorsanız, bunu desteklemek için test çerçevenizde bir özellik aramanız gerekir. Aşağıda, sürüm 5'ten bu yana tek bir testin yeniden denenmesini destekleyen Cypress'ten bir örnek verilmiştir:

 { "retries": { // Configure retry attempts for 'cypress run` "runMode": 2, // Configure retry attempts for 'cypress open` "openMode": 2, } }

Cypress'in yapılandırma dosyası cypress.json test yeniden denemelerini etkinleştirebilirsiniz. Burada, test koşucusu ve başsız modda yeniden deneme denemelerini tanımlayabilirsiniz.

Dinamik Bekleme Sürelerini Kullanma

Bu nokta, her türlü test için, ancak özellikle UI testi için önemlidir. Bunu yeterince vurgulayamam: Asla sabit bekleme süreleri kullanmayın - en azından çok iyi bir sebep olmadan. Bunu yaparsanız, olası sonuçları düşünün. En iyi durumda, çok uzun bekleme sürelerini seçerek test takımını olması gerekenden daha yavaş hale getirirsiniz. En kötü durumda, yeterince beklemeyeceksiniz, bu nedenle uygulama henüz hazır olmadığı için test devam etmeyecek ve testin kesintili bir şekilde başarısız olmasına neden olacaktır. Tecrübelerime göre, bu lapa lapa testlerin en yaygın nedenidir.

Bunun yerine dinamik bekleme sürelerini kullanın. Bunu yapmanın birçok yolu var, ancak Cypress bunları özellikle iyi idare ediyor.

Tüm Cypress komutlarının örtük bir bekleme yöntemi vardır: Komutun uygulandığı öğenin belirtilen süre boyunca DOM'da bulunup bulunmadığını zaten kontrol ederler - Cypress'in yeniden deneme yeteneğine işaret eder. Ancak, yalnızca varlığını kontrol eder , başka bir şey değil. Bu yüzden bir adım daha ileri gitmenizi tavsiye ederim - web sitenizin veya uygulamanızın kullanıcı arayüzünde gerçek bir kullanıcının da göreceği değişiklikleri, örneğin kullanıcı arayüzündeki veya animasyondaki değişiklikler gibi beklemenizi öneririm.

Bu örnek, seçici .offcanvas ile öğe üzerinde açık bir bekleme süresi kullanır. Test, yalnızca öğe, yapılandırabileceğiniz belirtilen zaman aşımına kadar görünür durumdaysa devam eder:

 // Wait for changes in UI (until element is visible) cy.get(#element).should('be.visible');

Cypress'te dinamik bekleme için bir başka güzel olasılık da ağ özellikleridir. Evet, taleplerin gerçekleşmesini ve yanıtlarının sonuçlarını bekleyebiliriz. Bu tür beklemeyi özellikle sık kullanırım. Aşağıdaki örnekte, beklenecek isteği tanımladık, yanıtı beklemek için bir wait komutu kullandık ve durum kodunu belirledik:

 // File: checkout-info.spec.js // Define request to wait for cy.intercept({ url: '/widgets/customer/info', method: 'GET' }).as('checkoutAvailable'); // Imagine other test steps here... // Assert the response's status code of the request cy.wait('@checkoutAvailable').its('response.statusCode') .should('equal', 200);

Bu şekilde, tam olarak uygulamamızın ihtiyaç duyduğu süre kadar bekleyebiliyoruz, bu da testleri daha kararlı hale getiriyor ve kaynak sızıntıları veya diğer çevresel sorunlar nedeniyle kesintiye uğrama olasılığını azaltıyor.

Kesintili Testlerde Hata Ayıklama

Artık tasarım gereği kesintili testleri nasıl önleyeceğimizi biliyoruz. Ama ya zaten lapa lapa bir testle uğraşıyorsanız? Ondan nasıl kurtulabilirsin?

Hata ayıklarken, kusurlu testi bir döngüye sokmak, düzensizlikleri ortaya çıkarmamda bana çok yardımcı oldu. Örneğin, bir testi 50 kez çalıştırırsanız ve her seferinde geçerse, testin kararlı olduğundan daha emin olabilirsiniz - belki de düzeltmeniz işe yaramıştır. Değilse, en azından lapa lapa testi hakkında daha fazla fikir edinebilirsiniz.

 // Use in build Lodash to repeat the test 100 times Cypress._.times(100, (k) => { it(`typing hello ${k + 1} / 100`, () => { // Write your test steps in here }) })

Bu lapa lapa test hakkında daha fazla bilgi edinmek özellikle CI'de zordur. Yardım almak için test çerçevenizin yapınız hakkında daha fazla bilgi alıp alamayacağına bakın. Ön uç testi söz konusu olduğunda, testlerinizde genellikle bir console.log kullanabilirsiniz:

 it('should be a Vue.JS component', () => { // Mock component by a method defined before const wrapper = createWrapper(); // Print out the component's html console.log(wrapper.html()); expect(wrapper.isVueInstance()).toBe(true); })

Bu örnek, test edilen bileşenin HTML çıktısını almak için bir console.log kullandığım bir Jest birim testinden alınmıştır. Bu günlük kaydı olanağını Cypress'in test çalıştırıcısında kullanırsanız, çıktıyı seçtiğiniz geliştirici araçlarında bile inceleyebilirsiniz . Ayrıca CI'de Cypress söz konusu olduğunda, bir eklenti kullanarak CI'nizin günlüğündeki bu çıktıyı inceleyebilirsiniz.

Günlüğe kaydetme konusunda destek almak için her zaman test çerçevenizin özelliklerine bakın. UI testinde çoğu çerçeve ekran görüntüsü özellikleri sağlar - en azından bir arıza durumunda otomatik olarak ekran görüntüsü alınır. Hatta bazı çerçeveler video kaydı sağlar, bu da testinizde neler olduğuna dair fikir edinmenize çok yardımcı olabilir.

Flakiness Kabuslarıyla Savaş!

İster ilk etapta önleyerek, isterse hata ayıklayıp ortaya çıkar çıkmaz düzelterek, sürekli olarak kesintili testleri araştırmak önemlidir. Bunları ciddiye almalıyız, çünkü uygulamanızdaki sorunlara işaret edebilirler.

Kırmızı Bayrakları Tespit Etmek

Tabii ki, ilk etapta lapa lapa testlerini önlemek en iyisidir. Hızlı bir şekilde özetlemek için, işte bazı kırmızı bayraklar:

• Test büyük ve çok fazla mantık içeriyor.
• Test çok sayıda kodu kapsar (örneğin, kullanıcı arayüzü testlerinde).
• Test, sabit bekleme sürelerini kullanır.
• Test önceki testlere bağlıdır.
• Test, kimliklerin, sürelerin veya demo verilerinin, özellikle de rastgele oluşturulmuş olanların kullanımı gibi %100 öngörülebilir olmayan verileri ileri sürer.

Bu makaledeki ipuçlarını ve stratejileri aklınızda tutarsanız, kesintili testleri daha gerçekleşmeden önleyebilirsiniz. Ve gelirlerse, nasıl hata ayıklayacağınızı ve düzelteceğinizi bileceksiniz.

Bu adımlar, test takımımıza olan güvenimi yeniden kazanmama gerçekten yardımcı oldu. Test takımımız şu anda kararlı görünüyor. Gelecekte sorunlar olabilir - hiçbir şey %100 mükemmel değildir. Bu bilgi ve bu stratejiler, onlarla başa çıkmama yardımcı olacak. Böylece, o lapa lapa test kabuslarıyla savaşma yeteneğime güvenim artacak.

Umarım en azından biraz acınızı ve çatlaklarla ilgili endişelerinizi giderebilmişimdir!

Daha fazla okuma

Bu konu hakkında daha fazla bilgi edinmek istiyorsanız, işte bana çok yardımcı olan bazı düzgün kaynaklar ve makaleler:

• "Pul" hakkında makaleler Cypress.io
• Filip Hric, Cypress.io “Testlerinizi Yeniden Denemek Aslında İyi Bir Şey (Yaklaşımınız Doğruysa),”
• "Test Kesintisi: Kesintili Testleri Belirleme ve Başa Çıkma Yöntemleri", Jason Palmer, Spotify Ar-Ge Mühendisliği
• "Google'da Kesintili Testler ve Bunları Nasıl Azaltıyoruz", John Micco, Google Test Blogu