GUI için kırılgan değil, korunabilir birim testleri nasıl yazılır?


16

GUI uygulamalarım için UI birim testleri yazmayı denedim ve ilk başta yazarken iyi çalışırken, kırılgan oldukları ve tasarım her değiştiğinde (yani, sıklıkla) kırıldığı sorunuyla karşı karşıya kalıyorum. GUI için sürdürülebilir birim testleri yaptırmamı sağlayacak bir dizi kılavuz bulmaya çalışıyorum.

Şimdilik keşfettiğim bir şey, "bu bileşen girdi verilerini bir yerde göstermeli" diyen testlerin iyi (ve HTML ile bu çok kolay). Bileşenin belirli bir bölümünün belirli bir durumunu kontrol eden testler genellikle kırılgandır. Kullanıcı davranışını ve temel iş mantığını (en önemli kısım olan) takip etmeye çalışan tıklama-tıklama-tıklama-bekle gibi testler genellikle kırılgan hale gelir. İyi testleri nasıl yazarım?


Daha kesin olmak gerekirse, tam olarak nasıl test edileceğimi değil, arayüzümde neyi test edebileceğim hakkında bazı modeller bilmek istiyorum . Adlandırma kuralları ve sabit tanımlayıcılar iyidir, ancak temel sorunu çözmeyin, yani GUI'ler çok değişir. Değişmesi muhtemel olmayan davranışları test etmek istiyorum. Test edilecek doğru şey nasıl bulunur?


1
@MichaelDurrant: Soruyu genel olarak UI testi ile ilgili olacak şekilde düzenlediniz, başlangıçta birim testi sordum. Entegrasyon testlerinin bakımını daha zor buluyorum ve mümkün olduğunda birim testlerini tercih ediyorum.
mik01aj

2
Bu sorunun bir parçası olduğunu düşünüyorum, çünkü temelde herhangi bir arayüzü tek başına birim test ederek test edemezsiniz, çünkü nedenleri bir şeye arayüz oluşturmaktır. GUI'ler bu açıdan farklı değildir.
jk.

m01, geri değiştirebilirsiniz. UI testlerinin genellikle entegre testler olduğunu düşünüyorum. Testler, mevcut olan tohum ve fikstür verilerine ve onlarla çalışan kullanıcı arayüzüne dayanma eğilimindedir. Mükemmel olan başka verilere dayanmayan gerçek UI testleriniz varsa. Ancak bunun nispeten nadir olduğunu gördüm.
Michael Durrant

2
ilgili ama yinelenen değil çünkü bu gui testleri ile ilgili: programmers.stackexchange.com/questions/109703/…
k3b

Yanıtlar:


3

GUI testlerinde sık karşılaşılan bir sorun ... Bu testlerin kırılgan olarak kabul edilmesinin temel nedeni , GUI'de gereksinimlerdeki bir değişiklik olmayan bir değişiklikten kurtulamamasıdır . Test kodunuzu, GUI'deki bir değişiklik testlerde tek bir yere ayrılacak şekilde yapılandırmaya çalışmalısınız.

Örnek olarak şu şekilde ifade edilen bir testi düşünün:

Kullanıcı telefon numarası alanına '999' girdiğinde ve kaydet düğmesine tıkladığında, hata mesajı açılır penceresinde 'geçersiz telefon numarası' yazmalıdır.

Doğrulama gereksinimi devam etse bile, arabirimi yeniden çalıştığınızda bu testin kırılması için burada bolca yer vardır.

Şimdi, bunu küçük bir alternatif ifadeye koyalım:

Kullanıcı telefon numarası olarak '999' değerini girip profil sayfasını kaydettiğinde, 'geçersiz telefon numarası' yazan bir hata göstermelidir

Test aynıdır, gereksinimler aynıdır, ancak bu tür testler kullanıcı arayüzünüz için bir makyajdan kurtulacaktır. Açıkçası kodu değiştirmeniz gerekecektir, ancak kod izole edilecektir. Profil sayfanız için bu tür on veya yirmi testiniz olsa ve hata mesajı görüntüleyen doğrulama mantığınızı javascript uyarılarından jquery-popup'lara taşımış olsanız bile, yalnızca hata mesajlarını kontrol eden tek test parçasını değiştirmeniz yeterlidir.


4

Bu yaygın bir sorundur. Ben dikkat:

  • Elemanları nasıl adlandırırsınız

    Öğeleri tanımlamak için css id veya class kullanın. Nesne benzersiz olduğunda CSS kimliğini kullanmayı tercih edin. Kullandığınız çerçeveyi düşünün, örneğin Ruby on Rails ile nameöznitelik otomatik olarak atanır ve (sezgisel olmayan) css id veya sınıfını kullanmaktan daha iyi olabilir

  • Elemanları nasıl tanımlarsınız.

    Veya table/tr/td/tdgibi formlar lehine konum belirleyicilerden kaçının . Uygun olduğunda veri özelliklerini kullanmayı düşünün. Daha da iyisi gibi önlemek düzeni etiketlerine denemek tamamen yüzden yukarıda ya bir yayılma ve kullanımını yani mesela ekleyebilirsiniz için ya gibi bir joker seçici nerede şimdi div, yayılma, td, vb olabilirtd[id="main_vehicle"td[class='alternates']<td><span id="main_vehicle">*[id="main_vehicle"]*

  • Yalnızca qa ve test için kullanılan teste özgü veri özelliklerini kullanma .

  • Elemanlar için gereksiz niteliklerden kaçının. Kendinizi aşağıdakileri kullanarak bulabilirsiniz:

    body.main div#vehicles > form#vehicle input#primary_vehicle_name

    Bununla birlikte, bu giriş alanının, tam bir araç kimliğine sahip bir formda ve bir ana sınıfı ve bir kimliğine sahip bir formun hemen bir çocuğuna sahip olan araç kimliğine sahip bir div içeren bir gövdeli bir sayfada kalmasını gerektirir. araç. Bu yapıda yapılan herhangi bir değişiklik ve test kırılır. Bu durumda,

    input#primary_vehicle_name

    öğeyi benzersiz bir şekilde tanımlamak için yeterlidir.

  • Görünür metne gönderme yapan testlerden kaçının. Sayfada kullanıcı tarafından gösterilen metin, site bakımı ve güncellemesi nedeniyle genellikle zaman içinde değişir, bu nedenle css id ve css sınıfı veya veri özellikleri gibi tanımlayıcılar kullanın. Gibi elementler form, inputve selectformlarda kullanılan genellikle örneğin id veya sınıf ile birlikte, aynı zamanda tanımlanması elemanlarının iyi parçalarıdır li.vehicleya input#first-vehicle da örneğin kendi tanımlayıcıları ekleyebilir <div data-vehicle='dodge'>. Bu şekilde, geliştiriciler ve tasarımcılar tarafından değiştirilmesi muhtemel öğe kimliklerini veya sınıflarını kullanmaktan kaçınabilirsiniz. Aslında zamanla geliştiriciler ve tasarımcılar ile çalışmanın ve isimler ve kapsamlar üzerinde anlaşmaya varmanın daha iyi olduğunu gördüm. Bu zor.

  • Sabit verilerin bakımı.

    Gerçek öğeleri tanımlamaya benzer şekilde, satır içi sabit kodlu seçiciden sayfa nesneleri lehine değerleri tanımlamaktan kaçının - değişkenler veya yöntemlerde tutulan ve böylece yeniden kullanılabilir ve merkezi olarak korunabilir. Sabit kodlanmış değerler için bu kalıbı izleyen javascript değişkenlerine örnekler:

    storedVars["eqv_auto_year"] = "2015";
    storedVars["eqv_auto_make_1"] = "ALFA ROMEO";
    storedVars["eqv_auto_make_2"] = "HONDA";`  
    

    Selenium Wiki ve Selenium Dokümanlarında Sayfa Nesneleri Hakkında Daha Fazla Bilgi

  • Geliştiricilerle iletişim.

    Teknik geliştiriciden bağımsız olarak 'geliştiriciler değişiklik yapar ve KG otomasyonunu bozar' bu bir iş akışı sorunudur. Şunlardan emin olmalısınız: herkes aynı takımdan; geliştirici aynı entegre testleri çalıştırır; her iki grupta standartlar üzerinde mutabık kalınmakta ve takip edilmektedir; done'nin tanımı UI testlerini çalıştırmayı ve muhtemelen güncellemeyi içerir; geliştiriciler ve test çiftleri test planları üzerinde ve her ikisi de bilet tımarlarına (Agile yapıyorsa) katılır ve tımarlamanın bir parçası olarak UI testi hakkında konuşurlar. Adlandırma için kullandığınız yaklaşım ve stratejilerin uygulama geliştiricilerle koordine edildiğinden emin olmalısınız. Aynı sayfaya ulaşmazsanız, nesne adlandırma konusunda çatışmayı seversiniz. Yakın zamanda bir ruby ​​projesi için oluşturduğum sayfa nesnesi yöntemlerine bazı örnekler:

    def css_email_opt_in_true
      'auto_policy[email_opt_in][value=1]'
    end 
    
    def css_phone_opt_in
      '*[name="auto_policy[phone_opt_in]"]'
    end 
    
    def css_phone_opt_in_true
      'input[name=phone_opt_in][value=true]'
    end 
    
    def css_credit_rating
      'auto_policy[credit_rating]'
    end
    

    Javascript değişkenleriyle aynı sayfa nesneleri şunlardır:

    storedVars["css_email_opt_in"] = "css=*[name='auto_policy[email_opt_in]']";
    storedVars["css_phone_opt_in"]="css=*[name='auto_policy[phone_opt_in]']";
    storedVars["css_phone_opt_in_true"]="css=input[name='phone_opt_in'][value=true]";
    storedVars["css_credit_rating"]="css=select[name='auto_policy[credit_rating]']";
    

2
Bunlar yararlı ipuçları, ve ben zaten zaten çoğunu takip ediyorum. Benim sorunum, bazı düğme için testler yazmak ve sonra aynı eylem başka bir yerden işlenirken bu düğme kaldırıldı oldu. Veya düğme orada kalır, ancak etiket değişir ve düğme bazı ek eylemler de gerçekleştirir.
mik01aj

1
Ahh, bunu bilmek güzel. Evet bu şeyler için iş akışı ve örgütsel qa-geliştirici etkileşimi üzerine odaklanırdım
Michael Durrant

1
Ayrıca, sorunuzu bulan ve onlarla ilgili bilmediğiniz veya bilmediğiniz tüm parçaları yerinde tutamayanlar için de bilgi gönderiyorum.
Michael Durrant

1
Son bülten puanımı geri bildirimlerinize göre genişlettim.
Michael Durrant

1
Öğeleri adlandırma ve tanımlama ve görünür metin kullanmama ile ilgili bölümleri güncelledim.
Michael Durrant

3

İnsanların önce MVC, MVP ve sunum yapan kişiler gibi şeyleri ve benzer tasarım modellerini geliştirmelerinin nedeni, iş mantığını kullanıcı arayüzünden ayırmaktı.

Açıkçası, görüntü kısmı sadece programı başlatarak ve gösterdiklerini kontrol ederek test edilebilir - başka bir deyişle, sadece kabul testlerinde test edilebilir.

Öte yandan, iş mantığının test edilmesi birim testlerde yapılabilir. Ve sorunuzun cevabı bu. Modeldeki her şeyi test edin ve mümkünse ve istiyorsanız, denetleyicinin kodunu da test edebilirsiniz.


GUI'ler çok değişiyor

Bu sadece değişen gereksinimleriniz olduğunda olabilir. Bir gereksinim değiştiğinde, kodu değiştirmek dışında bir yolu yoktur. İyi bir tasarım ve mimari oluşturmayı başarırsanız, değişiklik pek çok yerde yayılmaz.


2
Bence bu iyi bir nokta. Belki sadece MVC yanlış yapıyorum :) Btw, birçok kullanıcı için bir web platformu geliştirdiğinizde değişen gereksinimlerin kaçınılmaz olduğuna inanıyorum. Kullanıcılarınızın GUI'yi kullanmaya başlayana kadar nasıl davranacaklarını bilmiyorsunuz.
mik01aj

2

GUI etkileşim testleri, diğer test türlerinden daha fazla veya daha az kırılgan olmamalıdır. Yani; uygulamanız bir şekilde değişiyorsa, testlerin bunu yansıtacak şekilde güncellenmesi gerekir.

Karşılaştırma olarak:

Ünite testi

Orijinal : validateEmail()bir InvalidDataistisna atmalıdır. Hangi birim testi doğru bir şekilde kapsanmaktadır.

Değişim : validateEmail()bir InvalidEmailistisna atmalıdır. Şimdi testiniz yanlış, güncelliyorsunuz ve her şey tekrar yeşil.

GUI Testi

Orijinal : Geçersiz bir e-posta girilmesi, "Geçersiz veri girildi" içeren bir açılır hata kutusu ile sonuçlanır. Testleriniz tarafından doğru şekilde tespit edildi.

Değiştir : Geçersiz bir e-posta girilmesi, "Geçersiz e-posta girildi" ifadesini içeren satır içi bir hatayla sonuçlanır. Şimdi testiniz yanlış, güncelliyorsunuz ve her şey tekrar yeşil.


Girdiler ve çıktılar için test yaptığınızı unutmayın - bazı iyi tanımlanmış davranışlar. GUI testi veya Birim testi veya Entegrasyon testi vb.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.