Birim testleri kendi yöntemleri kullanmamalı mı?

Bugün bir " JUnit basics" videosu izliyordum ve yazar, programınızdaki belirli bir yöntemi test ederken, süreçte kendi yöntemlerinizi kullanmamanız gerektiğini söyledi.

Daha açık olmak gerekirse, argümanlar için bir isim ve soyadı alan bir kayıt oluşturma yöntemini test etmekten bahsediyordu ve bunları belirli bir tabloda kayıtlar oluşturmak için kullandı. Ancak, bu yöntemi test etme sürecinde , nihai sonucu kontrol etmek için veritabanını sorgulamak için diğer DAO yöntemlerini kullanmaması gerektiğini belirtti (bu kaydın gerçekten doğru verilerle oluşturulduğunu kontrol etmek için). Bunun için veritabanını sorgulamak ve sonucu kontrol etmek için ek JDBC kodu yazması gerektiğini iddia etti .

Onun iddiasının ruhunu anladığımı düşünüyorum: bir yöntemin test durumunun diğer yöntemlerin doğruluğuna (bu durumda, DAO yönteminin) bağlı olmasını istemiyorsunuz ve bu kendi onayınızı yazarak (yine) gerçekleştiriliyor / destekleyici kod (daha spesifik ve odaklanmış, bu nedenle daha basit kod olması gerekir).

Bununla birlikte, kafamın içindeki sesler kod çoğaltma, gereksiz ek çabalar vb. Gibi argümanlarla protesto etmeye başladı. Demek istediğim, eğer tüm test bataryasını çalıştırırsak ve tüm genel yöntemlerimizi (bu durumda DAO yöntemi de dahil olmak üzere) iyice test ediyoruz. diğer yöntemleri test ederken sadece bu yöntemlerden bazılarını kullanmak doğru olmaz mı? Eğer onlardan biri yapması gerekeni yapmıyorsa, o zaman kendi test durumu başarısız olur ve onu düzeltip test bataryasını tekrar çalıştırabiliriz. Kod çoğaltmaya gerek yok (yinelenen kod biraz daha basit olsa bile) veya boşa harcanan çabalar.

Yazdığım son Excel - VBA uygulamaları ( VBA için Rubberduck sayesinde uygun şekilde test edildi) nedeniyle bu konuda güçlü bir his duyuyorum , bu önerinin uygulanmasının algılanan bir fayda olmadan çok fazladan ek iş anlamına geleceği anlamına geliyor.

Lütfen bu konudaki görüşlerinizi paylaşır mısınız?

İddiasının ruhu gerçekten de doğru. Birim testlerinin amacı, kodu izole etmek, bağımlılıklardan arındırmak üzere test etmektir, böylece hatalı davranışların olduğu yerde hızlıca fark edilebilir.

Bununla birlikte, birim testi bir araçtır ve amaçlarınıza hizmet etmek içindir, dua edilmesi gereken bir sunak değildir. Bazen bu, bağımlılıkları bırakmak anlamına gelir, çünkü yeterince güvenilir çalışırlar ve onlarla alay etmek istemezsiniz, bazen birim testlerinizden bazıları aslında entegrasyon testleri olmasa da oldukça yakındır.

Nihayetinde puanlandırılmıyorsunuz, önemli olan test edilen yazılımın son ürünüdür; ancak kuralları ne zaman değiştirdiğinize ve takasların ne zaman yapılacağına karar verdiğiniz zaman dikkatli olmanız gerekir.

Sanırım bu terminolojiye bağlı. Çoğu için, bir "birim testi" çok özel bir şeydir ve tanımı gereği , test edilen ünite dışındaki herhangi bir koda (yöntem, işlev vb.) Bağlı olan bir geçiş / başarısız koşulu olamaz . Bu, bir veritabanı ile etkileşimi de içerir.

Diğerleri için "birim testi" terimi çok daha gevşektir ve uygulamanın entegre bölümlerini test eden test kodu da dahil olmak üzere her tür otomatik testi kapsar.

Bir test uzmanı (bu terimi kullanabilirsem) , testin birden fazla saf ünite koduna dayandığı temelinde bir birim testinden ayrılan bir entegrasyon testine diyebilir .

"Unit test" teriminin daha gevşek bir versiyonunu kullandığınızdan ve aslında bir "entegrasyon testinden" bahsettiğinizden şüpheleniyorum.

Bu tanımları kullanarak, bir "birim testinde" test edilen ünite dışındaki koda bağlı olmamanız gerekir. Bununla birlikte, bir "entegrasyon testinde", belirli bir kod parçasını uygulayan ve veri tabanını geçen kriterler açısından inceleyen bir test yazmak tamamen mantıklıdır.

Entegrasyon testlerine mi yoksa ünite testlerine mi yoksa her ikisine de mi bağlı olmanız gerektiği daha büyük bir tartışma konusudur.

Cevap evet ve hayır ...

Yalıtımda yapılan benzersiz testler, düşük seviyeli kodunuzun uygun şekilde çalıştığı temel çalışmasını ortaya koymanıza izin verdiği için mutlak bir zorunluluktur. Ancak daha büyük kütüphaneleri kodlarken, birimleri geçen testleri yaptırmanızı gerektiren kod alanlarını da bulacaksınız.

Bu üniteler arası testler kod kapsamı için iyidir ve testler uçtan uca işlevsellikte yapılır ancak bazı sakıncaları vardır:

• Neyin kırıldığını onaylamak için izole edilmiş bir test olmadan, başarısız bir "çapraz ünite" testi kodunuzda neyin yanlış olduğunu belirlemek için ek sorun giderme gerektirecektir
• Birimler arası testlere çok fazla güvenmek, SOLID Nesne Yönelimli kod yazarken her zaman olması gereken sözleşme zihniyetinden kurtulabilmenizi sağlar. İzole edilmiş testler tipik olarak anlamlıdır çünkü üniteleriniz yalnızca bir temel eylem gerçekleştirmelidir.
• Uçtan uca testler istenebilir ancak eğer bir test sizin bir veritabanına yazmanızı veya bir üretim ortamında gerçekleşmesini istemediğiniz bir işlemi gerçekleştirmenizi gerektiriyorsa tehlikeli olabilir. Bu, Mockito gibi alaycı çerçevelerin bu kadar popüler olmasının birçok nedeninden biri , çünkü bir nesneyi taklit etmenize ve yapmamanız gereken bir şeyi değiştirmeden bir uçtan uca testi taklit etmenize izin veriyor.

Günün sonunda, her ikisinden de bazılarına sahip olmak istersiniz. Testleri neden ilk başta yazdığınızı düşünün. Kodunuzun beklediğiniz şekilde çalıştığından emin olmak için oradalar. Bunu gerçekleştirmek için ne yapmanız gerekiyorsa sorun değil.

Üzücü ama gerçek gerçek şu ki, eğer otomatik testler kullanıyorsanız, o zaman zaten birçok geliştiriciye ayak bastınız. İyi test uygulamaları, bir geliştirme ekibinin zorlu son teslim tarihleriyle karşı karşıya kalması durumunda kayması gereken ilk şeydir. Silahlarınıza sadık kaldığınız ve kodunuzun nasıl bir performans göstermesi gerektiğinin anlamlı bir yansıması olan birim testleri yazdığınız sürece, testlerinizin ne kadar "saf" olduğuna dikkat edemem.

Bir koşulu sınamak için diğer nesne yöntemlerini kullanmadaki bir sorun, birbirinizi iptal eden hataları özleyeceğinizdir. Daha da önemlisi, zor bir test uygulamasının acısını kaçırıyorsunuz ve bu acı size temel kurallarınız hakkında bir şeyler öğretiyor. Ağrılı testler artık daha sonra ağrılı bakım anlamına geliyor.

Senin birimleri küçültmek sınıf, Refactor bölmek ve test etmek kolay kadar yeniden olmadan Nesnenizin kalanı reimplementing. Kodunuzun veya testlerinizin daha da basitleştirilemediğini düşünüyorsanız, yardım alın. Her zaman şanssız görünen ve temiz bir şekilde test edilmesi kolay olan ödevleri alan bir meslektaşı düşünmeye çalışın. Ondan yardım isteyin, çünkü bu şans değildir.

Test edilen işlevsellik birimi 'sürekli ve geri alınabilen veridir' ise, o zaman gerçek bir veritabanına depolanan, veritabanına referansları tutan tüm nesneleri yok eden ve ardından veriyi almak için kodu çağıran birim test testine sahip olurdum. geri nesneler.

Veritabanında bir kaydın oluşturulup oluşturulmadığının test edilmesi, sistemin geri kalanına maruz kalan işlevsellik biriminin test edilmesinden ziyade, depolama mekanizmasının uygulama ayrıntılarıyla ilgileniyor gibi görünmektedir.

Sahte bir veritabanı kullanarak performansı artırmak için testi kısayol olarak kullanmak isteyebilirsiniz, ancak tam olarak bunu yapan ve bu testlerden geçen bir sistemle sözleşmelerinin sonunda kalan, ancak veritabanında hiçbir şey saklamayan müteahhitlerim var. Sistemin yeniden başlatılması arasında.

Birim testindeki "birim" in "kod birimi" mi, yoksa "işlev birimi" mi, belki de pek çok kod birimi tarafından konserde oluşturulduğunu iddia edebilirsiniz. Bunu yararlı bir ayrım olarak görmüyorum - aklımda tuttuğum sorular 'test size sistemin işletme değeri sağlayıp sağlamadığı hakkında bir şey söylüyor mu' ve 'uygulama değişirse test kırılgan mı?' Açıklandığı gibi testler, sistemi TDD yaparken kullanışlıdır - henüz 'veritabanı kaydından nesne al' yazmamışsınızdır, ancak işlevsellik biriminin tamamını test edemezsiniz - ancak uygulama değişikliklerine karşı kırılgan olursunuz. tam çalışma test edilebilir olduktan sonra bunları çıkarın.

Ruh doğru.

İdeal olarak, bir de birim test , bir test edilir birimi (bir tek yöntem ya da küçük sınıfı).

İdeal olarak, tüm veritabanı sistemini saplarsınız. Yani, yönteminizi sahte bir ortamda çalıştırır ve doğru DB API'lerini doğru sırayla çağırdığından emin olursunuz. Sen explicitely olumlu do not kendi yöntemlerden birini test ederken DB test etmek istiyorum.

Avantajları çoktur. Her şeyden önce, testler hızlı şekilde körelir, çünkü doğru bir DB ortamı oluşturma ve daha sonra geri alma konusunda sıkıntı duymanıza gerek yoktur.

Tabii ki, bu baştan sona doğru yapmayan herhangi bir yazılım projesinde yüce bir amaçtır. Ancak, birim sınama ruhu budur .

Bu testten farklı olan özellik testleri, davranış testleri vb. Gibi başka testler bulunduğunu unutmayın - "test" ile "birim test" i karıştırmayın.

En az bir çok önemli nedeni vardır değil size veritabanı uygulaması değiştirirseniz, bu birim testlerinin hepsini yeniden yazmak gerekecek: veritabanı ile etkileşime iş kod için birim testlerinde doğrudan veritabanı erişimi için. Bir sütunu yeniden adlandırın, kodunuz için veri eşleyici tanımınızdaki tek bir satırı değiştirmeniz yeterli. Ancak veri eşleyicinizi test ederken kullanmazsanız, bu sütuna başvuran her bir birim testini de değiştirmeniz gerektiğini göreceksiniz . Bu, özellikle arama ve değiştirme için daha az elverişli olan daha karmaşık değişiklikler için olağanüstü miktarda bir çalışmaya dönüşebilir.

Ayrıca, veri eşleyicinizi veri tabanıyla konuşmak yerine soyut bir mekanizma olarak kullanmak, veritabanına olan bağımlılığı tamamen ortadan kaldırmayı kolaylaştırır ; bu şimdi ilgili olmayabilir, ancak binlerce birim testine ve hepsine ulaştığınızda Bir veritabanına çarpıyorsanız, bu bağımlılığı ortadan kaldırmak için onları kolayca yeniden düzenleyebildiğiniz için teşekkür ederiz, çünkü test takımınız birkaç dakikadan birkaç saniyeye kadar uzayabilir, bu da verimliliğinize büyük bir fayda sağlayabilir.

Sorunuz doğru çizgileri düşündüğünüzü gösteriyor. Şüphelendiğiniz gibi, birim testleri de koddur. Onların kod tabanınızın geri kalanında olduğu gibi gelecekteki değişikliklere uyum sağlamaları ve bakımlarını kolaylaştırmak da aynı derecede önemlidir. Onları okunabilir tutmaya ve çoğaltmayı ortadan kaldırmaya çalışın, bunun için daha iyi bir test paketine sahip olacaksınız. Ve iyi bir test takımı kullanılan bir tanesidir. Ve kullanılan bir test paketi hataları bulmaya yardımcı olurken, kullanılmayan bir test ise sadece değersizdir.

Ünite testi ve entegrasyon testi hakkında öğrenirken öğrendiğim en iyi ders, test yöntemleri değil test davranışlarıdır. Başka bir deyişle, bu nesne ne yapar?

Bu şekilde baktığımda, verilere devam eden bir yöntem ve onu geri okuyan başka bir yöntem test edilebilir olmaya başlıyor. Metotları özel olarak test ediyorsanız, elbette, aşağıdaki gibi her bir metot için bir test yapmanız gerekir:

@Test
public void canSaveData() {
    writeDataToDatabase();
    // what can you assert - the only expectation you can have here is that an exception was not thrown.
}

@Test
public void canReadData() {
    // how do I even get data in there to read if I cannot call the method which writes it?
}

Bu sorun, test yöntemlerinin bakış açısı nedeniyle oluşur. Yöntemleri test etme. Test davranışları WidgetDao sınıfının davranışı nedir? Widget'lar devam ediyor. Tamam, widget'ın sürdüğünü nasıl doğrularsın? Kalıcılığın tanımı nedir? Bu, yazarken tekrar okuyabileceğiniz anlamına gelir. Öyleyse birlikte okumak + birlikte yazmak bir test olur ve bence daha anlamlı bir test olur.

@Test
public void widgetsCanBeStored() {
    Widget widget = new Widget();
    widget.setXXX.....
    // blah

    widgetDao.storeWidget(widget);
    Widget stored = widgetDao.getWidget(widget.getWidgetId());
    assertEquals(widget, stored);
}

Bu mantıklı, tutarlı, güvenilir ve benim görüşüme göre anlamlı bir test.

Diğer cevaplar, izolasyonun ne kadar önemli olduğuna, pragmatik ve gerçekçi tartışmaya ve bir birim testinin bir veritabanını sorgulayıp sorgulayamayacağına odaklanır. Bunlar aslında soruya cevap vermiyor.

Bir şeyin saklanıp saklanmadığını test etmek için, saklamanız ve sonra tekrar okumanız gerekir. Bir şeyin saklanıp saklanmadığını test edemezsiniz, okumanıza izin verilmiyorsa. Veri depolamasını, veri alımından ayrı olarak test etmeyin. Size hiçbir şey söylemediğiniz testlerle biteceksiniz.

Yakalamaya önceden karar verdiğiniz bir başarısızlık örneği, test edilen nesnenin bir önbellek katmanı kullanması ancak verileri gerektiği gibi sürdürememesidir. Sonra nesneyi sorgularsanız, "evet, yeni ad ve adresim var" der, ancak yapması gerekeni yapmadığı için testin başarısız olmasını istersiniz.

Alternatif olarak (ve tek sorumluluk ihlaline bakmadan), dizenin UTF-8 kodlu bir versiyonunu bayt yönelimli bir alana sürmenin gerekli olduğunu varsayalım, ancak aslında Shift JIS'i devam ettiriyor. Başka bir bileşen veritabanını okuyacak ve UTF-8'i görmeyi beklemektedir, bu nedenle gereksinim vardır. Ardından, bu nesne boyunca gidiş dönüş doğru adı ve adresi bildirebilir çünkü Shift JIS'ten geri çevirir, ancak hata testiniz tarafından algılanmaz. İnşallah daha sonraki bir entegrasyon testi ile tespit edilecektir, ancak birim testlerin amacı, sorunları erken yakalamak ve hangi bileşenin sorumlu olduğunu tam olarak bilmektir.

Eğer onlardan biri yapması gerekeni yapmıyorsa, o zaman kendi test durumu başarısız olur ve onu düzeltip test bataryasını tekrar çalıştırabiliriz.

Bunu üstlenemezsiniz, çünkü dikkatli olmazsanız, karşılıklı olarak bağımlı bir dizi test yazarsınız. "Kurtarıyor mu?" test, test ettiği kaydetme yöntemini ve ardından kaydetme işlemini onaylamak için yükleme yöntemini çağırır. "Yüklüyor mu?" test, test fikstürünü ayarlamak için kaydetme yöntemini ve ardından sonucu kontrol etmek için test ettiği yükleme yöntemini çağırır. Her iki test de, test etmedikleri yöntemin doğruluğuna dayanmaktadır, yani hiçbiri test ettiği yöntemin doğruluğunu test etmez.

Burada bir sorun olduğuna dair bir ipucu, farklı birimleri deneyen iki testin aslında aynı şeyi yaptığıdır . Her ikisi de bir ayarlayıcıyı ve ardından bir alıcıyı çağırır, ardından sonucun orijinal değer olup olmadığını kontrol edin. Ancak, belirleyicinin / alıcı çiftinin birlikte çalıştığını değil, belirleyicinin verileri sürdürdüğünü test etmek istediniz. Yani bir şeylerin yanlış olduğunu biliyorsunuz, sadece neyi bulmanız ve testleri düzeltmeniz gerekiyor.

Kodunuz ünite testi için iyi tasarlanmışsa, verilerin gerçekten test edilen yönteme göre doğru şekilde devam edilip edilmediğini test etmenin en az iki yolu vardır:

• veritabanı arabirimini alay edin ve alayınıza uygun işlevlerin üzerinde beklenen değerlerle çağrıldığını kaydedin. Bu, testin yapması gerekeni yapar ve klasik birim testidir.

• Verilerin doğru şekilde sürdürülüp sürdürülmediğini kaydetmek için aynı amaca sahip gerçek bir veri tabanını iletin. Ancak, sadece "evet, doğru verileri aldım" diyen alaycı bir işleve sahip olmak yerine, testiniz doğrudan veritabanından okur ve doğru olduğunu onaylar. Bu mümkün olan en saf test olmayabilir , çünkü bir veritabanı motorunun tamamı yüceltilmiş bir taklit yazmak için kullanması oldukça büyük bir şeydir, çünkü bir şeyler yanlış olsa bile bir test geçişi yapan bazı inceliklere bakmam daha fazla (benim için) Taahhüt edilmemiş bir işlem görebildiğim için yazmak için kullanılan ile aynı veritabanı bağlantısını kullanmamalı). Ama doğru olanı test ediyor ve en azından tam olarak bunu biliyorsun. herhangi bir sahte kod yazmak zorunda kalmadan tüm veritabanı arayüzü uygular!

Bu yüzden, test uygulamasının verilerini JDBC tarafından veri tabanından okudum ya da veri tabanını alayıp atamadım. Her iki durumda da, üniteyi, bir şeyler yanlış olsa bile doğru gözükmek için aynı sınıftaki diğer yanlış yöntemlerle fikirleşmesine izin verirsem, izole edebileceğimden daha iyi izole ederek test edebiliyorum. Bu nedenle , yöntemini test ettiğim bileşene güvenmekten başka , doğru verinin devam ettirildiğini kontrol etmek için herhangi bir uygun araç kullanmak istiyorum .

Kodunuz ise değil birim test için iyi tasarlanmış, o zaman, hiçbir seçim olabilir kimin yöntem bir enjekte bağımlılık olarak veritabanını kabul etmeyebilir test etmek istediğiniz nesne çünkü. Bu durumda, test edilen üniteyi izole etmenin en iyi yolu hakkındaki tartışma, test edilen üniteyi izole etmenin ne kadar yakın olacağı üzerine yapılan bir tartışmaya dönüşür. Sonuç olsa aynıdır. Arızalı birimler arasındaki komplolardan kaçınabiliyorsanız, o zaman yaparsınız, uygun zamana ve koddaki hataları bulmakta daha etkili olacağını düşündüğünüz herhangi bir şeye tabidir.

Bu şekilde yapmayı seviyorum. Bu sadece kişisel bir seçimdir çünkü bu ürünün sonucunu, sadece onu üretme yöntemini etkilemeyecektir.

Bu, test ettiğiniz uygulama olmadan veritabanınıza sahte değerler ekleyebilme olasılıklarına bağlıdır.

İki testiniz olduğunu varsayalım: A - veritabanını okumak B - veritabanına eklemek (A'ya bağlıdır)

Eğer A geçerse, o zaman B sonucunun bağımlılıklara değil B'de test edilen kısma bağlı olacağından emin olabilirsiniz. A başarısız olursa, B için yanlış bir negatif olabilir. Hata B veya A'da olabilir. A başarılı oluncaya kadar emin olamazsınız.

Birimin testinde bazı sorgular yazmaya çalışmam çünkü uygulamanın arkasındaki DB yapısını bilmemelisiniz (veya değişebilir). Yani, test durumunuz kodunuzun kendisi yüzünden başarısız olabilir. Test için bir test yazmazsan, ama test için testi kim test edecek?

Sonunda, test etmek istediğiniz şeye iniyor.

Bazen, sınıfınızın sağlanan arayüzünü test etmek yeterli olabilir (örneğin, kayıt oluşturulur ve saklanır ve daha sonra, belki de "yeniden başlatma" işleminden sonra alınabilir). Bu durumda, test için verilen yöntemleri kullanmak iyidir (ve genellikle iyi bir fikirdir). Bu, örneğin depolama mekanizmasını değiştirmek istiyorsanız (farklı veritabanı, test için hafıza içi veritabanı, ...) testlerin tekrar kullanılmasını sağlar.

Bunun, sınıfın buna nasıl uyduğunu değil (bu durumda kayıt oluşturma, saklama ve alma) kontratına uymaya özen gösterdiğiniz anlamına geldiğini unutmayın. Ünite testlerinizi akıllıca yaratırsanız (doğrudan bir sınıfa karşı değil bir arayüze karşı), arayüzün sözleşmesine uymaları gerektiğinden farklı uygulamaları test edebilirsiniz.

Öte yandan, bazı durumlarda, işlerin nasıl devam ettiğini gerçekten doğrulamanız gerekir (belki başka bir işlem de o veri tabanında doğru formatta olan verilere dayanır?). Şimdi sadece sınıftan doğru kaydı almaya güvenemezsiniz, bunun yerine veritabanında doğru bir şekilde saklandığını doğrulamanız gerekir. Ve bunu yapmanın en doğrudan yolu veritabanını sorgulamak.

Artık sadece sınıfına sözleşmesine bağlı kalarak (yarat, sakla ve geri al) değil, aynı zamanda bunu nasıl başardığını da umursuyorsun (çünkü devam eden verinin başka bir arayüze uyması gerekiyor). Bununla birlikte, şimdi testler hem sınıf arayüzüne hem de depolama formatına bağlıdır, bu yüzden onları tamamen yeniden kullanmak zor olacaktır. (Bazıları bu tür testlere “entegrasyon testleri” diyebilir.)