Küçük veya kozmetik değişiklikler nedeniyle başarısız olmayan Selenyum (veya benzeri) için testleri nasıl yazabilirsiniz?

Geçen haftayı selenyum öğreniyorum ve piyasaya sürmek üzere olduğumuz bir web sitesi için bir dizi web testi yapıyorum. öğrenmek harika oldu ve bazı xpath ve css konum tekniklerini aldım.

benim için sorun olsa da, küçük değişikliklerin testleri kırması olduğunu görüyoruz.

bu yüzden selenyum (veya benzeri) testler yazdınız mı ve testlerin kırılgan doğasıyla nasıl başa çıkıyorsunuz (veya kırılgan olmalarını nasıl durduruyorsunuz) ve selenyum için ne tür testler kullanıyorsunuz?

testing selenium

— Sam J
kaynak

Testlerde küçük değişiklikler kırılıyorsa, değişiklikler yapıldıktan sonra testler yapılmaz - bu, testlerin bütün noktasıdır. Ayrıca, geliştiricilerin testlerin (varlığı) farkındalığı eksik görünüyor.

— talonx

@talonx - sadece bu tür bir testi çalıştırmak yeterli değildir, eğer küçük bir değişiklik süitte büyük bir değişiklikle sonuçlanırsa, geliştirici, ci kutusu veya test kullanıcıları tarafından çalıştırılsalar da sorunlu olacaktır

— FinnNk

@FinnNK: Kabul et - küçük değişiklikler büyük değişikliklerle sonuçlanmamalıdır. Bu, test senaryolarının, değişiklikleri yapan geliştiricilerle temas halinde olmayan bir kişi tarafından yazıldığı anlamına geliyor - bir iletişim boşluğu gibi kokuyor.

— talonx

@talonx: Kullanıcı arayüzü testleri doğası gereği kırılgandır ve birim testlerden çok daha uzun zaman alır. Bunlar özel bir mücadeledir, bu yüzden @ Sam'in organizasyonundaki geliştiricilerle ilgili sonuçlara atlamam.

— azheglov

Başlığı değiştirdim - umarım sorunun biraz daha temsilcisidir ve biraz daha az olumsuzdur.

— Jon Hopkins

Yanıtlar:

Selenyum'un amacı UI güdümlü entegrasyon testleri oluşturmaktır .

Entegrasyon testleri, birlikte dağıtıldığında sisteminizin tüm bileşenlerinin doğru çalıştığını doğrular. Entegrasyon testleri yeterli bir test stratejisi değildir ve birim test ve kabul testi gibi farklı bir odağa sahip diğer test stratejilerini tamamlar .

UI güdümlü testler doğal olarak kırılgandır, ancak Selenyum ve Watir kayıt ve oynatma araçlarının ilk günlerinden bir adım ötede . Bu sorunla başa çıkmanın birkaç yolu vardır - işte bazı dünya standartlarında uzmanların tavsiyelerinin bir derlemesi:

Tüm test kapsamınızı bu tür testlerden almaya çalışmayın . Robert C. Martin entegrasyon testleri ile kod kapsamınızın yaklaşık% 20 olması gerektiğini savunuyor . Giriş birkaç uygulama katmanı uzakta olduğunda tüm yürütme yollarını test etmek pratik değildir.

Test kapsamının çoğunu birim ve kabul testlerinden alın . Finnj'in cevabında Gojko Adzic'in makalelerine bağlantılar arayın . Adziç, kabul testleriyle ve kullanıcı arayüzünü atlayarak iş mantığını test etme konusunda defalarca tartıştı.

Ancak UI güdümlü testlerin bir kısmının hala yazılması gerekiyor . "İş mantığınızı kullanıcı arayüzü üzerinden test etmeyin" yanı sıra bazı pratik önerilere de ihtiyacınız var. Başlangıç noktası olarak Patrick Wilson-Welsh'ın blogunu öneriyorum .

— azheglov
kaynak

Patrickwilsonwelsh.com için bağlantı daha çalışma ve bunun için diğer kaynak değil .. !!

— MarmiK

Önemsiz bir sayıyı geçtikten sonra böyle testler oluştururken en önemli şey simetrik değişiklik fikridir - koddaki küçük bir değişiklik test takımında küçük bir değişiklikle sonuçlanmalıdır.

Örneğin, 100 testte birinin adını iki metin kutusuyla topladığınızı varsayalım. Bu testleri sorunsuz bir şekilde yazarsanız (veya belki de kayıttan yürütmeyi kullanıyorsanız) değiştirmek için 100 testiniz olacaktır. Bunun yerine bir 'ad girin' adımı yazdıysanız ve bunu doğrudan selenyum kullanmak yerine testlerinizde kullanırsanız, değişikliklerinizi yapmak için yalnızca 1 yeriniz vardır. Kaç tane soyutlama katmanı kullandığınıza bağlamınıza bağlı olacaktır - ancak soyutlamayı kullanmak, testlerinizi sürdürülebilir kılmak için uzun bir yol kat edecektir.

İkinci önemli şey, seçicilerinizin en önemli ve değişme olasılığı en düşük olanı temel aldığından emin olmaktır. Bazen bu bir kimlik veya sınıf olabilir veya bir öğenin içindeki veya çevresindeki metin olabilir. Her zaman en basit seçiciyi (örneğin bir kimlik) tercih edin, ancak bazen bunu başarmak için xpath gibi bir şey kullanmanız gerekir.

Bu tür bir test söz konusu olduğunda Gojko Adzic'in blogunda birçok harika tavsiyesi var - Ölüm Sinüsü'ne ve özellikle nasıl önleneceğine bakın .

— FinnNk
kaynak

iyi ipuçları FinnNk - Sık kullanılan yöntemleri (giriş, kenar çubuğu widget'ları vb.) soyutladım - böylece testler değiştiğinde hasar azalır. Ne yazık ki, bazı widget'ları oluşturan ve dom'daki konumlarına göre widget'lar için id'ler oluşturan uygun bir sistem kullanıyoruz, bu nedenle bir şey hareket ettiğinde testler bozuldu.

— Sam J

Genellikle bir öğeyi tanımlamanın bir yolunu bulabilirsiniz - belki de öğenin içerdiği bazı metinler veya belki de her zaman başka bir şeyle aynı göreceli konuma sahiptir. Son olarak, son çare olarak, size tam kontrol sağlayan selenyum kullanarak öğeleri bulmak için özel konum belirleyici stratejileri de tanımlayabilirsiniz (örneğin, ad taban adı ve sonuna eklenmiş bazı arbiter şeyler içeren öğeler arıyorsanız, veya asp.net web formlarında).

— FinnNk

Test, kodun beklendiği gibi davranmasını sağlar. Testleriniz düzenli olarak kesilirse, testler ya doğru olanı test etmez ya da geliştiriciler testleri umursamazlar.

Şahsen, bir <div>etiketin varlığı bir testi geçerse, testin kesinlikle çevreleyen etiketlere kesinlikle bağlı olduğunu ve daha yumuşak bir yaklaşımın gerektiğini düşünüyorum.