E2E Testleri Yazarken Nelere Dikkat Edilmeli #frontend@twiliosendgrid

Twilio SendGrid'de, yeni bir özelliğin veya sayfa geliştirme döngüsünün sonuna doğru uçtan uca (E2E) testler yazıyoruz ve tüm parçaların son kullanıcı açısından ön uç ile arka uç arasında düzgün bir şekilde bağlandığından ve çalıştığından emin oluyoruz.

Kendi özel kurum içi Ruby Selenium çerçevemiz, WebdriverIO ve öncelikle Cypress gibi çeşitli E2E test çerçevelerini ve kitaplıklarını iki yıldan fazla bir süre boyunca denedik, tüm dünyaya geçişimizi belgeleyen blog yazısı serisinin birinci ve ikinci bölümünde vurgulandı. çözümler. Kullandığımız çerçeve veya kitaplıktan bağımsız olarak, hangi özellikleri otomatikleştirebileceğimiz ve E2E testleri için yazabileceğimiz konusunda aynı soruları soruyorduk. Hangi özellikleri test edebileceğimizi belirledikten sonra, testleri yazmak ve kurmak için aynı genel stratejiyi tekrar tekrar uyguladığımızı da fark ettik.

Bu blog yazısı, belirli bir kitaplık veya çerçevede E2E testleri yazmak için önceden herhangi bir bilgi gerektirmez, ancak web uygulamalarını gördüyseniz ve sayfaların doğru çalıştığını test etmek için tarayıcıdaki şeyleri en iyi nasıl otomatikleştireceğinizi merak ettiyseniz yardımcı olur. E2E testleri hakkında nasıl düşünmeniz gerektiği konusunda size yol göstermeyi amaçlıyoruz, böylece bu soruları ve test yazmak için genel stratejiyi seçebileceğiniz herhangi bir çerçeveye uygulayabilirsiniz.

Bir E2E testini otomatikleştirip otomatikleştiremeyeceğinizi sormanız gereken sorular

E2E testleri yazmak söz konusu olduğunda, uygulamamızda test ettiğimiz sayfalardaki akışların belirli kriterleri karşıladığından emin olmamız gerekiyor. Bir E2E testinin otomatikleştirilmesinin mümkün olup olmadığını belirlemek için kendimize sorduğumuz bazı üst düzey soruları gözden geçirelim.

1. API gibi güvenilir bir yolla her testten önce kullanıcı verilerini belirli bir duruma geri döndürmek mümkün müdür? Bir kullanıcıyı istediğiniz duruma güvenli bir şekilde sıfırlamanın bir yolu yoksa, otomatikleştirilemez ve dağıtımdan önce engelleme testlerinizin bir parçası olarak çalışması beklenemez. Aynı zamanda, bir kullanıcıyı UI aracılığıyla belirli bir duruma geri döndürmek bir anti-kalıptır ve genellikle deterministik değildir, çünkü yavaştır ve UI aracılığıyla adımların otomatikleştirilmesi zaten yeterince sorunludur. Tarayıcıda bir sayfa açmak zorunda kalmadan kullanıcının durumunu sıfırlamak için API çağrıları yapmak daha güvenilirdir. Diğer bir alternatif ise, mevcut bir hizmetiniz varsa, her testten önce uygun verilerle yeni kullanıcılar oluşturmaktır. Kalıcı bir kullanıcıyı sıfırladığımız veya her testten önce bir kullanıcı oluşturduğumuz sürece, sayfada test ettiğimiz kısımlara odaklanabiliriz.

2. Test etmeyi planladığımız özellik, API veya sistem üzerinde kontrolümüz var mı? Faturalandırma veya başka herhangi bir özellik için güvendiğiniz bir üçüncü taraf hizmetiyse, bunlarla dalga geçmenin veya belirli değerlerle deterministik bir şekilde çalışmasını sağlamanın bir yolu var mı? Kesintiyi azaltmak için test üzerinde mümkün olduğunca fazla kontrol elde etmek istiyorsunuz. Başka hiçbir şeyden etkilenmemesi için, test çalıştırması başına izole kaynaklara veya verilere sahip özel test kullanıcıları oluşturabilirsiniz.

3. Hizmet veya özelliğin kendisi makul bir zaman aşımı süresi içinde çalışacak kadar tutarlı mı? Genellikle yoklama uygulamanız veya belirli verilerin işlenip veritabanına aktarılmasını beklemeniz gerekebilir (daha yavaş eşzamansız güncellemeler ve tetiklenen e-posta olayları gibi). Bu hizmetler makul ve güvenilir bir zaman aralığında sıklıkla ortaya çıkıyorsa, belirli DOM öğelerinin görünmesini veya verilerin güncellenmesini beklerken uygun yoklama zaman aşımlarını ayarlayabilirsiniz.

4. Bir sayfada etkileşim kurmamız gereken öğeleri seçebilir miyiz? Üzerinde kontrolünüz olmayan ve değiştiremeyeceğiniz iframe'ler veya oluşturulan öğelerle mi uğraşıyorsunuz? Bir sayfadaki öğelerle etkileşim kurmak için, kimlikler veya sınıf adları yerine "data-hook" veya "data-testid" öznitelikleri gibi daha özel seçiciler ekleyebilirsiniz. Kimlikler ve sınıf adları, genellikle stiller ile ilişkilendirildikleri için değişmeye daha yatkındır. Aksi takdirde, stil bileşenlerinden veya CSS modüllerinden karma sınıf adlarını veya kimliklerini seçmeye çalıştığınızı hayal edin. Üçüncü taraf tarafından oluşturulan öğeler veya tepki-seç gibi açık kaynak bileşen kitaplıkları için, bu öğeleri bir "veri kancası" özniteliğine sahip bir üst öğeyle sarabilir ve altındaki çocukları seçebilirsiniz. iframe'lerle uğraşmak için, ileri sürmemiz ve üzerinde hareket etmemiz gereken DOM öğelerini çıkarmak için özel komutlar oluşturduk ve buna daha sonra bir örnek vereceğiz.

Dikkate alınması gereken daha çok husus var, ancak hepsi tek bir soruda özetleniyor: Bu E2E testini tutarlı ve zamanında tekrar edip aynı sonuçları elde edebilir miyiz?

E2E testleri yazmak için genel strateji

1. Otomatikleştirebileceğimiz yüksek değerli test senaryolarını belirleyin . Bazı örnekler, bir özellik akışının çoğunu kapsayan mutlu yol testlerini içerir: bir kullanıcının profil bilgileri için UI üzerinden CRUD işlemleri gerçekleştirme, bazı veriler verilen sonuçları eşleştirmek için bir tabloyu filtreleme, bir gönderi oluşturma veya bir API anahtarı ayarlama. Bununla birlikte, diğer uç durumlar ve hata işleme, birim ve entegrasyon testleri ile ele alınması daha iyi olabilir. Test senaryoları listenizi kısaltmanıza yardımcı olması için önceki bölümde bahsettiğimiz soruları gözden geçirin.

2. API'yi mümkün olduğunca kurarak veya yıkarak bu testleri nasıl tekrarlayacağınızı düşünün. Yüksek değerli, otomatikleştirilebilir test senaryoları için API aracılığıyla hangi şeyleri ayarlamanız gerektiğini not etmeye başlayın. Kullanıcının sayfalandırma için yeterli filtrelenebilir veriye sahip olmaması, kullanıcının verilerinin 30 günlük bir zaman aralığında süresinin dolması veya başarılı veya eksik veriden arta kalan bazı verileri muhtemelen ayırmamız gerekiyorsa, kullanıcıya uygun veriler tohumlamak bazı örneklerdir. mevcut test tekrar başlamadan önce testler. Testler, son test çalıştırmasının nasıl başarılı veya başarısız olduğuna bakılmaksızın, kendini aynı tekrarlanabilir durumda çalıştırabilmeli ve kurabilmelidir.

Şunu düşünmek önemlidir: Özelliğin yalnızca istediğim kısmını test edebilmek için bu kullanıcının verilerini başlangıç ​​noktasına nasıl sıfırlayabilirim?

Örneğin, bir kullanıcının bir gönderi ekleme yeteneğini test etmek istiyorsanız, sonunda kullanıcının gönderi listesinde görünmesi için gönderi önce silinmelidir.

3. Müşterinizin yerine geçin ve bir özellik akışını tamamen bitirmek için gereken kullanıcı arayüzü adımlarını takip edin. Bir müşterinin tam bir akışı veya eylemi tamamlaması için adımları kaydedin. Kullanıcının her adımdan sonra neyi görmesi veya neyi görmemesi veya neyle etkileşime geçmesi gerektiğini takip edin. Kullanıcıların eylemleri için uygun olay dizileriyle karşılaştıklarından emin olmak için yol boyunca akıl sağlığı kontrolleri ve iddialar yapacağız. Daha sonra akıl sağlığı kontrollerini otomatik komutlara ve iddialara çevireceğiz.

4. Belirli seçiciler ekleyerek ve sayfa nesneleri (veya başka herhangi bir sarmalayıcı türü) uygulayarak değişiklikleri koruyun ve akışları otomatikleştirin. Nasıl manevra yapacağınızı ve bir özellik akışından nasıl geçeceğinizi öğrenmek için yazdığınız bu adımları gözden geçirin. Kullanıcının etkileşimde bulunduğu düğmeler, modlar, girdiler, tablo satırları, uyarılar ve kartlar gibi öğelere "veri kancası" öznitelikleri gibi daha özel seçiciler ekleyin. İsterseniz, eklediğiniz seçiciler aracılığıyla bu öğelere referanslarla sayfa nesneleri, sarmalayıcılar veya yardımcı dosyalar oluşturabilirsiniz. Ardından, sayfanın işlem yapılabilir öğeleriyle etkileşim kurmak için yeniden kullanılabilir işlevleri uygulayabilirsiniz.

5. Oluşturduğunuz yardımcılar ile kaydettiğiniz kullanıcı adımlarını Cypress testlerine çevirin. Testlerde, genellikle API aracılığıyla bir kullanıcıda oturum açarız ve oturumun açık kalması için her test senaryosu çalıştırılmadan önce oturum tanımlama bilgisini saklarız. Ardından, tutarlı bir başlangıç ​​noktası elde etmek için API aracılığıyla kullanıcının verilerini kurar veya parçalara ayırırız. Her şey yerinde olduğunda, doğrudan özelliğimiz için test edeceğimiz sayfayı ziyaret ediyoruz. Akış için oluşturma, güncelleme veya silme akışı gibi adımları yürüterek, yol boyunca sayfada ne olması veya görünmesi gerektiğini iddia ederek ilerliyoruz. Testleri hızlandırmak ve kesintileri azaltmak için, kullanıcı arayüzü üzerinden durumu sıfırlamaktan veya oluşturmaktan kaçının ve test etmek istediğiniz parçalara odaklanmak için oturum açma sayfasından giriş yapmak veya kullanıcı arayüzü üzerinden bir şeyleri silmek gibi şeyleri atlayın. Bu kısımları her zaman "önce" veya "Her Birinden Önce" kancalarında yaptığınızdan emin olun. Aksi takdirde, "after" veya "afterEach" kancalarını kullandıysanız, testler arada başarısız olabilir, bu da temizleme adımlarınızın hiçbir zaman çalıştırılmamasına ve sonraki test çalıştırmalarının başarısız olmasına neden olabilir.

6. Çekiçle dövün ve testin pul pul dökülmesini sağlayın. Testleri uyguladıktan ve yerel olarak birkaç kez geçtikten sonra, bir çekme isteği oluşturmak, onu hemen birleştirmek ve testlerin test takımınızın geri kalanıyla bir programa göre çalışmasını sağlamak veya bunları dağıtım adımlarınızda tetiklemek cazip gelebilir. Bunu yapmadan önce:

1. 1. İlk olarak, kullanıcıyı çeşitli durumlarda bırakmayı deneyin ve doğru kurulum adımlarına sahip olduğunuzdan emin olmak için testlerinizin hala başarılı olup olmadığına bakın.
   2. Ardından, dağıtım akışlarınızdan biri sırasında tetiklendiğinde testlerinizi paralel olarak çalıştırmayı araştırın. Bu, kaynaklara aynı kullanıcılar tarafından basılıp basılmadığını ve herhangi bir yarış koşulunun olup olmadığını görmenizi sağlar.
   3. Ardından, herhangi bir zaman aşımını artırmanız veya herhangi bir seçiciyi ayarlamanız gerekip gerekmediğini görmek için testlerinizin bir Docker kapsayıcısında başsız modda nasıl çalıştığını gözlemleyin.

Amaç, testlerinizin farklı koşullar altında tekrarlanan test çalıştırmalarında nasıl davrandığını görmek ve onları olabildiğince kararlı ve tutarlı hale getirmektir, böylece testleri düzeltmek için geri dönmek için daha az zaman harcar ve ortamlarımızdaki gerçek hataları yakalamaya daha fazla odaklanırız.

İşte, `cy.login(kullanıcı adı, şifre)` adında bir oturum açma global destek komutu oluşturduğumuz örnek bir Cypress test ortak levha düzeni. test ettiğimiz sayfalara. Ayrıca, API üzerinden bazı kurulumlar gerçekleştiriyor veya yıkıyoruz ve aşağıda gösterildiği gibi her seferinde oturum açma sayfasını atlıyoruz.

Biten düşünceler

Hangi E2E çözümünün en iyi kullanılacağını karşılaştırmanın yanı sıra, E2E testi için uygun zihniyeti benimsemek de önemlidir. Öncelikle test etmek istediğiniz özelliğin otomatikleştirilme gereksinimlerine uyup uymadığı hakkında sorular sormanız çok önemlidir. Doğrulamaya çalıştığınız şeye odaklanabilmeniz için kullanıcıyı veya verileri güvenilir bir şekilde (API aracılığıyla olduğu gibi) belirli bir duruma sıfırlamanın yolları olmalıdır.

Kullanıcınızı veya verilerinizi uygun başlangıç ​​noktasına sıfırlamanın güvenilir bir yolu yoksa, belirli yapılandırmalara sahip kullanıcılar oluşturmak için araçlar ve API'ler oluşturmaya bakmalısınız. Testleri olabildiğince istikrarlı ve tutarlı hale getirmek için kontrol edebileceğiniz şeylerle alay etmeyi de düşünebilirsiniz. Aksi takdirde, ekibinizle birlikte değeri ve takasları göz önünde bulundurmalısınız. Bu özellik, yeni kod değişiklikleri yapıldığında birim testlerine veya manuel regresyon testine bırakmanız gereken bir özellik mi?

E2E testlerinde otomatikleştirebileceğiniz bu özellikler için, kullanıcılarınızın ana mutlu yol akışlarını kapsamak genellikle çok değerlidir. Bir kez daha, istediğiniz herhangi bir çerçeve veya kitaplık ile E2E testleri yazarken işleri zamanında ve tutarlı bir şekilde tekrarlanabilir hale getirin ve düzensizlikleri ortadan kaldırın.

Spesifik olarak Cypress E2E testleri hakkında daha fazla bilgi için aşağıdaki kaynaklara göz atın:

• Selvi Testleri Yazmaya 1.000 Ayak Genel Bakış
• TypeScript Cypress Testlerinizdeki Her Şey
• Cypress Testlerinde E-posta Akışlarıyla Başa Çıkmak
• Cypress Testlerinizi Yapılandırma, Düzenleme ve Birleştirme Fikirleri
• Docker, Buildkite ve CICD ile Cypress Testlerini Entegre Etme