TDD testleri ne kadar ayrıntılı olmalıdır?

Tıbbi yazılım durumuna dayalı TDD eğitimi sırasında şu hikayeyi uyguluyoruz: "Kullanıcı Kaydet düğmesine bastığında, sistem hasta eklemeli, cihaz eklemeli ve cihaz veri kayıtları eklemelidir".

Son uygulama şöyle görünecektir:

if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed)
{
   AddPatient();
   AddDevice();
   AddDeviceDataRecords();
}

Uygulamanın iki yolu var:

1. Her birinin bir yöntemi doğruladığı üç test (AddPatient, AddDevice, AddDeviceDataRecords) çağrıldı
2. Her üç yöntemi de doğrulayan bir test çağrıldı

İlk durumda, yan tümce koşulu durumunda yanlış bir şey olursa, her üç test de başarısız olur. Ancak ikinci durumda test başarısız olursa, neyin yanlış olduğundan emin değiliz. Hangi yolu tercih edersiniz.

Ancak ikinci durumda test başarısız olursa, neyin yanlış olduğundan emin değiliz.

Bu büyük ölçüde testin ne kadar iyi hata mesajları ürettiğine bağlı olacağını düşünüyorum. Genel olarak, bir yöntemin çağrıldığını doğrulamanın farklı yolları vardır; Örneğin, sahte bir nesne kullanırsanız, test sırasında hangi beklenen yöntemin çağrılmadığını açıklayan kesin bir hata mesajı verir. Yöntemin çağrının etkilerini algılayarak çağrıldığını doğrularsanız, açıklayıcı bir hata iletisi oluşturmak size kalmıştır.

Uygulamada, seçenek 1 ve 2 arasındaki seçim de duruma bağlıdır. Eski bir projede yukarıda gösterdiğiniz kodu görürsem, durum yerine getirildiğinde 3 yöntemin her birinin doğru şekilde çağrıldığını doğrulamak için Vaka # 2'nin pragmatik yaklaşımını seçerim. Şu anda bu kod parçasını geliştiriyorsam, 3 yöntem çağrısı büyük olasılıkla ayrı ayrı noktalarda (muhtemelen günler veya aylar birbirinden uzakta) tek tek eklenecektir, bu yüzden yeni, ayrı bir birim testi ekleyeceğim Her aramayı doğrulamak için.

Ayrıca, her iki yöntemde de, ayrı ayrı yöntemlerin her birinin yapması gerekeni yaptığını doğrulamak için ayrı birim testlerine sahip olmanız gerektiğini unutmayın.

Örneğinizdeki Ayrıntı düzeyi, birim ve kabul testleri arasındaki fark gibi görünüyor.

Bir birim testi, mümkün olduğunca az bağımlılıkla tek bir işlevsellik birimini test eder. Sizin durumunuzda, 4 birim test olabilir

• AddPatient hasta ekliyor mu (yani ilgili veritabanı fonksiyonlarını çağırıyor)?
• AddDevice bir cihaz ekliyor mu?
• AddDeviceDataRecords kayıtları ekler mi?
• Örneğinizdeki değiştirilen ana işlevi AddPatient, AddDevice ve AddDeviceFunctions çağrı yapar

Unittest'ler geliştiriciler içindir , bu nedenle kodlarının teknik olarak doğru olduğuna güvenirler

Kabul testleri, birleşik işlevselliği kullanıcı açısından test etmelidir. Kullanıcı hikayeleri boyunca modellenmeli ve mümkün olduğunca üst düzeyde olmalıdırlar. Bu nedenle, işlevlerin çağrılıp çağrılmadığını kontrol etmek zorunda değilsiniz, ancak kullanıcı tarafından görülebilir bir fayda sağlanmışsa :

kullanıcı verileri girdiğinde, Tamam'ı tıklar ve ...

• ... hasta listesine gidiyor, verilen isimde yeni bir hasta görmeli
• ... cihaz listesine gidiyor, yeni bir cihaz görmeli
• ... yeni cihazın ayrıntılarına gidiyor, yeni veri kayıtlarını görmeli

kabul testleri müşteriler içindir veya onlarla daha iyi iletişim kurmak içindir.

"Ne tercih edersiniz" sorunuzu cevaplamak için: şu anda sizin için daha büyük bir sorun nedir, hatalar ve regresyon (=> daha fazla birim testi) veya büyük resmi anlama ve resmileştirme (=> daha fazla kabul testi)

Uygulamanın iki yolu var:

Bu yanlış.

Her birinin bir yöntemi doğruladığı üç test (AddPatient, AddDevice, AddDeviceDataRecords) çağrıldı

Çalıştığından emin olmak için bunu yapmanız gerekir .

Her üç yöntemi de doğrulayan bir test çağrıldı

API'nın çalıştığından emin olmak için de bunu yapmanız gerekir .

Sınıf - bir birim olarak - tamamen test edilmelidir. Her yöntem.

Üç yöntemi de kapsayan bir testle başlayabilirsiniz, ancak size fazla bir şey söylemez.

test başarısız olursa, tam olarak neyin yanlış olduğundan emin değiliz.

Doğru. Bu yüzden tüm yöntemleri test edersiniz .

Sen gerekir kamu arayüzü test. Bu sınıf üç artı bir şey yaptığından (kullanıcı hikayesi nedeniyle bir yöntemle paketlenmiş olsalar bile) dört şeyi de test etmelisiniz. Üç düşük seviye ve bir paket.

Birim testlerimizi, birçok kez bir yönteme eşlenen (kodunuzu iyi yazdıysanız) anlamlı işlevsellik cümleleri için yazıyoruz , ancak bazen büyüyerek birçok yöntemi kapsayan.

Örneğin, sisteminize bir hasta eklemenin çağrılacak bazı alt rutinlere (alt işlevler) ihtiyacı olduğunu düşünün:

1. VerifyPatientQualification
2. EnsureDoctorExistence
3. CheckInsuranceHistory
4. EnsureEmptyBed

Bu işlevlerin her biri için birim testi de yazabiliriz.

Takip ettiğim basit bir kural, testi isminin tam olarak ne yaptığını açıklayacak şekilde adlandırmaktır. Testin adı çok karmaşık hale gelirse, testin belki de çok fazla şey yaptığının bir işaretidir. Örneğin, seçenek 2'de önerdiğiniz şeyi yapmak için bir testi adlandırmak, PatientIs AddedWhenSaved, DeviceIs AddedWhenSaved, DataRecordsWhenSaved gibi üç ayrı testten çok daha karmaşık olan PatientIs AddedDeviceIs AddedAndDeviceDataRecordsWhenSaved gibi görünebilir. Ayrıca, BDD'den öğrenilebilecek derslerin, her testin doğal bir dilde tanımlanabilecek tek bir gereksinimi gerçekten temsil ettiği oldukça ilginç olduğunu düşünüyorum.