Sadece düzeltildikten sonra test edilebilen bir hata için nasıl TDD yapabilirsiniz?


13

İşte bir örnek: Web uygulamam sürüklenebilir öğeler içeriyor. Bir öğeyi sürüklerken, tarayıcı bir "hayalet görüntü" oluşturur. Sürüklerken "hayalet görüntü" kaldırmak istiyorum ve bu davranış için bir test yazın.

Benim sorunum başlangıçta bu hatayı düzeltmek için hiçbir fikrim yok ve ben bir test yazmanın tek yolu onu düzelttikten sonra olmasıdır.

Gibi basit bir işlevde let sum = (a, b) => a - b, herhangi bir kod yazmadan önce neden sum(1, 2)eşit olmadığına dair bir test yazabilirsiniz 3.

Tarif ettiğim durumda, test edemiyorum, çünkü doğrulamanın ne olduğunu bilmiyorum (iddianın ne olması gerektiğini bilmiyorum).

Açıklanan soruna bir çözüm:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

Bunun çözüm olduğunu bilmiyordum. Çevrimiçi çözümü bulduktan sonra testi bile yazamadım, çünkü gerçekten işe yarayıp yaramadığını bildiğim tek yol, kodumun içine bu kodu eklemek ve istenen etkiye sahipse tarayıcı ile doğrulamaktı. Test, TDD'ye aykırı olan koddan sonra yazılmak zorundaydı.

TDD'nin bu soruna yaklaşımı nedir? Testi koddan önce yazmak zorunlu mu yoksa isteğe bağlı mı?


2
O zaman araştırmayı yap. Bir çözüm bulun ... sonra testinizi, düzeltmenizi ve yeniden düzenleyicinizi yazın. Testler, kodunuzun çalıştığını (sadece) doğrulamak değil, tam çözümünüzü gelecekte kanıtlamak içindir. Başlangıçta testinizi başarısız olacak şekilde oluşturursunuz, hangi özelliği test edersiniz? Başlamanın bir yolu bu.
Juan Carlos Eduardo Romaina Ac

@Kilian Foth: Soru başlığınızı değiştirerek iyi niyetlerinizi görüyorum, ancak düzenlemeniz cevabımın geçersiz kısımlarını geçersiz kıldı. Dahası, yeni unvanınız IMHO'nun soru gövdesine iyi uymuyor. Bu yüzden bir geri alma yaptım, suç yok.
Doc Brown

Yanıtlar:


26

Sizi doğru anladığımda, bir çözüm bulduktan sonra "hayalet görüntü" örneğiniz için güvenilir bir otomatik test bile yazamazsınız , çünkü doğru davranışı doğrulamanın tek yolu ekrana bakmak ve hayalet görüntü olup olmadığını kontrol etmektir. artık. Bu bana orijinal başlığınızın yanlış soruyu sorduğu izlenimini veriyor. Asıl soru şu olmalı:

  • grafik kullanıcı arabiriminin belirli bir davranışını otomatik olarak nasıl test edebilirim?

Ve cevap - birkaç çeşit kullanıcı arayüzü sorunu için değil . Tabii, bir şekilde sorunu gösteren kullanıcı arayüzünü otomatikleştirmeye çalışabilir ve ekran görüntüsü karşılaştırması gibi bir şey uygulamaya çalışabiliriz, ancak bu genellikle hataya eğilimli, kırılgan ve uygun maliyetli değildir.

Özellikle "test sürüşü" UI tasarımı veya önceden yazılmış otomatik testlerle UI iyileştirmeleri tam anlamıyla imkansızdır. UI tasarımını bir iyileştirme yaparak "yönlendirirsiniz", sonucu bir insana (kendiniz, bazı test kullanıcılarına veya bir kullanıcıya) gösterir ve geri bildirim istersiniz.

TDD'nin gümüş bir kurşun olmadığı gerçeğini kabul edin ve bazı sorunlar için manuel testler otomatik testlerden daha mantıklı. Sistematik bir test süreciniz varsa, belki bazı özel testçilerle yapabileceğiniz en iyi şey, vakayı test planlarına eklemektir.


Genel olarak UI testi önemsiz değildir; oluşturulan görüntüyü sabitleyebilir, simüle edebilir / otomatikleştirebilir, makro kaydedebilirsiniz, özel bir çözüm kullanabilirsiniz, manuel test kullanabilirsiniz, duruma ve otomatik UI testinin projeniz için ne kadar gerekli olduğuna bağlıdır.
esoterik

1
@esoterik: evet, ve tüm bu otomatik teknikler yazdığım gibi hataya açık ve kırılgandır. Bildiğim tek kırılgan olmayan yaklaşım manuel testtir.
Doc Brown

3
Cevabın için teşekkür ederim. Sanırım haklısın, yanlış bir şekilde TDD'de gümüş bir kurşun bulmayı umuyorum. Test etmek istediğimi test etmenin etkili bir yolu yok gibi görünüyor - ekran görüntüsü karşılaştırması ve yukarıdakilerin hepsi yeterli bir yatırım getirisi vermiyor. Özellikle ekran görüntüsü karşılaştırması çok zaman alıcı ve söylediğiniz gibi hataya yatkın görünüyor.
maximedupre

1
@maximedupre: Bu reklamı sorunu çözmeye çalışan bir araç için buldu , ancak yine de makale genel olarak cevabımla aynı fikirde görünüyor.
Doc Brown

5

TDD'nin bu soruna yaklaşımı nedir? Testi koddan önce yazmak zorunlu mu yoksa isteğe bağlı mı?

Bunun bir yolu, başak çözeltisinin bir analogu uygulamaktır .

James Shore bunu şu şekilde tarif etti:

Daha fazla bilgiye ihtiyaç duyduğumuzda küçük, izole deneyler yapıyoruz.

Temel fikir, neler olduğunu anlarken tasarım araçlarını indirmenizdir. Yataklarınızı aldıktan sonra, tasarım araçlarını tekrar alırsınız.

İşin püf noktası: araştırmanızdaki bilgiyi üretim kodu tabanınıza geri getiriyorsunuz, ancak kodu getirmiyorsunuz . Bunun yerine, disiplinli tasarım tekniklerinizi kullanarak yeniden yaratırsınız.

Kurslar için atlar.

DÜZENLE:

Kusur sadece insan gözüyle görülebiliyorsa testi nasıl otomatikleştirebilirsiniz?

Biraz farklı bir yazım önermek istiyorum: "Testi otomatikleştirmek uygun maliyetli değilse bir testi nasıl otomatikleştirebilirsiniz?"

Cevap, elbette, "bilmiyorsun". Bunun yerine, uygulamanızı iki parçaya ayırmaya çalışın - testin maliyet etkin olduğu büyük bir parça ve kırılması çok kolay olan daha küçük bir parça.

Bir yazılım tasarımı oluşturmanın iki yolu vardır: Bunun bir yolu, o kadar basit hale getirmektir ki, hiçbir eksiklik yoktur - CAR Hoare

Üçüncü taraf koduyla çalışırken, üçüncü taraf kitaplığı için proxy görevi gören çok ince bir kod kabuğuna sahip olacağız. Testte, bu kabuğu , istenen efektleri ürettiğinden endişe etmeden protokolü doğrulayan bir "test double" ile değiştiriyoruz .

Kodların gerçek üçüncü taraf koduyla entegrasyonunun test edilmesi için diğer tekniklere (görsel doğrulama, teknik destek çağrıları, iyimserlik ...) güveniyoruz.

Üçüncü taraf kitaplığını yükselttiğinizde varsayımlarınızın hala geçerli olup olmadığını kontrol edebilmeniz için bazı tanıtım eserlerini saklamak yararlı olabilir.


James Shore'nin söylediklerini seviyorum. Şu anda www.letscodejavascript.com screencast'ı takip ediyorum ve çok şey öğreniyorum. Beni işaret ettiğin bağlantıları okuyacağım.
maximedupre

Haklısın, TDD ve sivri uçlar hakkında daha fazla şey okudum. Aslında kontrol etmeye çalıştığınız kodun test etmeden önce nasıl göründüğünü bilmeniz gerekir. TDD size daha önce bilmediğiniz hiçbir şeyi öğretemez, ancak potansiyel olarak size James Shore'u yeniden yorumlayarak öğrenmeniz gereken bazı şeyler gösterebilir. Bu notta TDD: Spike, Test, Fail, Pass, Refactor gibi bir ek adım önermek istiyorum.
maximedupre

0

Sadece farklı bir bakış açısı ile UI / GUI etrafındaki testler, kabul testleri (özellik / iş iş akışı merkezli testler) açısından biraz daha iyi yapılabilir.

Web için, selenyum webdriver gibi çerçevelerin doğru teste yaklaşma potansiyeline sahip olduğunu düşünüyorum, ancak başlamak için ek yük biraz fazla olabilir ve sadece birim testlere göre TDD ile görülen akışta bir değişikliktir. .

Durumunuza özellikle yardımcı olacak bölüm Sayfa Nesne Modeli ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html ). Bu, çalışma zamanı GUI'sinin yöntemlere / olaylara / sınıf üyelerine ad vererek belirli bir kodla açıkça eşlenmesini sağlar.

Buna karşı ana argümanlar genel gider ve bu genel gider genellikle geliştirme döngüsünün sonunda görülebilir. Genel olarak, testlerin çoğaltılan işler oluşturduğu anlaşılan bir sarıcı gerektirmesidir.

İleride, ekibin ve işin maliyetine / yararına bağlı olacaktır, bu nedenle beklentileri ve görüşleri belirlemek tartışmak yararlı bir konu olabilir.


Aslında son zamanlarda TDD e2e / fonksiyonel testleri (selenyum webdriver ile) deniyordum, ama yükü kesinlikle dediğin gibi çok büyük. Verimli bir geliştirici olamazsınız ve e2e testleriyle TDD yapabilirsiniz. POM kullanıyordum, ancak bana sağladığı tek fayda, test kod tabanımdaki gelişmiş bir mimariydi.
maximedupre

Evet, farklı şirketlerden farklı ekiplere gördüğüm daha uygulanabilir bir seçenek, bir ekip / ekip üyesinin yalnızca kullanıcı arayüzünden manuel testler yapmak üzere tasarlandığı daha manuel bir SQA sürecini dahil etmek olacağını düşünüyorum. Testlerde çoğunlukla ekran görüntüleri ve adım adım belgeler bulunur. En azından böyle bir şey, bir uygulamayı test etmek için bazı kanıtlar üretecektir.
eparham7861

0

Hayalet görüntü neye benziyor? Bilinen bir renkte sahte bir kullanıcı arayüzü oluşturduysanız, sürüklenebilir bileşeninizi nereye koydunuz? Hayalet görüntü olsaydı belirli bir renk olur muydu?

Daha sonra test, hayalet görüntünün renginin eksikliğini test edebilir.

Böyle bir test makul dayanıklı ve yapılabilir olabilir.


Yapılabilir - evet. Dayanıklı - bağlıdır. Kullanıcı arayüzünüzün rengini / temasını değiştirmek, testlerinizi kırabilir, bu bana çok dayanıklı gelmiyor.
Sean Burton

1
Size tüm kullanıcı arayüzünü test etmeyeceksiniz. Sürükle-bırak bileşeni için bir kukla kullanıcı arayüzü oluşturursunuz.
Esben Skov Pedersen

Önerdiğiniz şeyi nasıl başaracağınızdan emin değilim. Benim durumumda bir hayalet görüntü sürüklenen öğenin yarı opak bir kopyası olurdu. Sürükle ve bırak sırasında hayalet görüntü her zaman imleci takip ediyor.
maximedupre

Evet. Sürüklemeyi otomatikleştirmeniz gerekir. Bu bir birim test değil, bir e2e testi olacaktır.
Esben Skov Pedersen
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.