Eminim çoğunuz çok sayıda otomatik test yazıyorsunuzdur ve ayrıca birim testi yaparken bazı yaygın tuzaklarla karşılaşmışsınızdır.
Sorum şu: Gelecekte sorun yaşamamak için test yazarken herhangi bir davranış kuralına uyuyor musunuz? Daha spesifik olmak gerekirse: İyi birim testlerin özellikleri nelerdir veya testlerinizi nasıl yazarsınız?
Dilden bağımsız öneriler teşvik edilir.
Yanıtlar:
Kaynakları ekleyerek başlayayım - JUnit ile Java'da Pragmatik Birim Testi (C # -Nunit ile de bir sürüm var .. ama bende bu var .. çoğunlukla agnostik. Önerilir.)
İyi Testler BİR YOLCULUK olmalıdır (Kısaltma yeterince yapışkan değildir - bunu doğru anladığımdan emin olmak için kitapta çıkarmam gereken kopya kağıdının bir çıktısı var ..)
Profesyonel : Uzun vadede, üretim kadar çok test koduna sahip olacaksınız (daha fazla değilse), bu nedenle test kodunuz için aynı iyi tasarım standardını takip edin. İyi faktörlü yöntem-sınıfları, niyetleri ortaya çıkaran isimler, Yineleme yok, iyi isimlerle testler, vb.
İyi testler de Hızlı çalışır . yarım saniyeden fazla süren herhangi bir test .. üzerinde çalışılmalıdır. Bir çalışma için test paketi ne kadar uzun sürer .. o kadar az sıklıkta çalıştırılır. Geliştirici ne kadar fazla değişiklik olursa, koşular arasında gizlice girmeye çalışır .. eğer herhangi bir şey bozulursa .. hangi değişikliğin suçlu olduğunu anlamak daha uzun sürer.
2010-08 Güncellemesi:
Bunların dışında, diğerlerinin çoğu, düşük fayda sağlayan işleri azaltan yönergelerdir: örneğin, 'Sahip olmadığınız kodu test etmeyin' (örneğin, üçüncü taraf DLL'ler). Alıcıları ve ayarlayıcıları test etmeye devam etmeyin. Maliyet-fayda oranına veya kusur olasılığına dikkat edin.
Buradaki cevapların çoğu, testleri kendileri (nasıl) yazmaktan ziyade, genel olarak birim testi en iyi uygulamalarını (ne zaman, nerede, neden ve ne) ele alıyor gibi görünüyor. Soru "nasıl" bölümünde oldukça spesifik göründüğünden, bunu şirketimde yaptığım "kahverengi çanta" sunumundan alarak yayınlayacağımı düşündüm.
1. Uzun, açıklayıcı test yöntemi adları kullanın.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Testlerinizi bir Düzenleme / Harekete Geçme / Onaylama tarzında yazın .
3. Onaylarınızla her zaman bir hata mesajı sağlayın.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
4. Testin nedenini yorumlayın - iş varsayımı nedir?
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
5. Her test, dokunduğu herhangi bir kaynağın durumunu daima geri döndürmelidir
Bu hedefleri aklınızda bulundurun (Meszaros'un xUnit Test Patterns kitabından uyarlanmıştır)
Bunu kolaylaştıracak bazı şeyler:
XUnit çerçevenizle de entegrasyon testi yapabileceğinizi unutmayın, ancak entegrasyon testleri ile birim testlerini ayrı tutun
Testler izole edilmelidir. Bir test diğerine bağlı olmamalıdır. Dahası, bir test harici sistemlere dayanmamalıdır. Diğer bir deyişle, test etmek için kod değil, kod kod on.You sizin entegrasyonu veya fonksiyonel testlerin bir parçası olarak bu etkileşimleri test edebilirsiniz bağlıdır.
Harika birim testlerinin bazı özellikleri:
Bir test başarısız olduğunda, sorunun nerede olduğu hemen anlaşılmalıdır. Sorunu izlemek için hata ayıklayıcıyı kullanmanız gerekiyorsa, testleriniz yeterince ayrıntılı değildir. Test başına tam olarak bir iddianın olması burada yardımcı olur.
Yeniden düzenleme yaptığınızda, hiçbir test başarısız olmamalıdır.
Testler o kadar hızlı çalışmalıdır ki, onları çalıştırmaktan asla çekinmezsiniz.
Tüm testler her zaman geçmelidir; deterministik olmayan sonuç yok.
Birim testleri, tıpkı üretim kodunuz gibi iyi faktörlendirilmelidir.
@Alotor: Bir kitaplığın yalnızca harici API'sinde birim testleri olması gerektiğini öneriyorsanız, katılmıyorum. Dışarıdan arayanlara göstermediğim sınıflar da dahil olmak üzere her sınıf için birim testleri istiyorum. (Bununla birlikte, özel yöntemler için testler yazma ihtiyacı hissediyorsam, o zaman yeniden düzenleme yapmam gerekir. )
DÜZENLEME: "Test başına bir değerlendirme" nin neden olduğu yinelemeyle ilgili bir yorum vardı. Spesifik olarak, bir senaryo oluşturmak için bir kodunuz varsa ve daha sonra bununla ilgili birden çok iddiada bulunmak istiyorsanız, ancak test başına yalnızca bir iddianız varsa, kurulumu birden çok testte çoğaltabilirsiniz.
Ben bu yaklaşımı benimsemiyorum. Bunun yerine, senaryo başına test fikstürleri kullanıyorum . İşte kaba bir örnek:
[TestFixture]
public class StackTests
{
[TestFixture]
public class EmptyTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
}
[TestMethod]
[ExpectedException (typeof(Exception))]
public void PopFails()
{
_stack.Pop();
}
[TestMethod]
public void IsEmpty()
{
Assert(_stack.IsEmpty());
}
}
[TestFixture]
public class PushedOneTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
_stack.Push(7);
}
// Tests for one item on the stack...
}
}
Peşinde olduğunuz şey, test edilen sınıfın davranışlarının tasviridir.
Temel amaç, sınıfın davranışına olan güveninizi artırmaktır.
Bu, özellikle kodunuzu yeniden düzenlemeye bakarken yararlıdır. Martin Fowler'ın ilginç bir makalesi var web sitesinde testlerle ilgili .
HTH.
şerefe
Rob
Test başlangıçta başarısız olmalıdır. O zaman onları geçmesini sağlayan kodu yazmalısınız, aksi takdirde hatalı ve her zaman başarılı olan bir test yazma riskiyle karşı karşıya kalırsınız.
Yukarıda bahsedilen Pragmatik Birim Testi kitabındaki Sağ BICEP kısaltmasını beğendim :
Şahsen, doğru sonuçları aldığınızı kontrol ederek (1 + 1, bir toplama işlevinde 2 döndürmelidir), aklınıza gelebilecek tüm sınır koşullarını deneyerek (toplamı olan iki sayıyı kullanmak gibi) oldukça ileriye gidebileceğinizi düşünüyorum. add işlevindeki maksimum tamsayı değerinden daha büyüktür) ve ağ hataları gibi hata koşullarını zorlar.
İyi testlerin sürdürülebilir olması gerekir.
Karmaşık ortamlar için bunu nasıl yapacağımı tam olarak çözmedim.
Kod tabanınız yüz binlerce veya milyonlarca satır koda ulaşmaya başladığında tüm ders kitapları tutarsız gelmeye başlar.
İyi mimari, etkileşim patlamasının bir kısmını kontrol edebilir, ancak kaçınılmaz olarak sistemler daha karmaşık hale geldikçe, otomatik test sistemi de onunla birlikte büyür.
İşte değiş tokuşlarla uğraşmaya başladığınız yer:
Ayrıca karar vermeniz gerekiyor:
test durumlarını kod tabanınızda nerede saklıyorsunuz?
Sonsuza kadar devam edebilirim, ama benim açımdan şu:
Testlerin sürdürülebilir olması gerekir.
Bu ilkeleri , herhangi bir geliştirici için okumasının önemli olduğunu düşündüğüm Bu MSDN Magazine makalesinde bir süre önce ele almıştım.
"İyi" birim testlerini tanımlama yöntemim, aşağıdaki üç özelliğe sahip olmalarıdır:
Jay Fields'ın birim testleri yazma konusunda pek çok iyi tavsiyesi var ve en önemli tavsiyeleri özetlediği bir yazı var . Orada, bağlamınız hakkında eleştirel bir şekilde düşünmeniz ve tavsiyenin sizin için değer olup olmadığına karar vermeniz gerektiğini okuyacaksınız. Burada bir sürü harika yanıt alırsınız, ancak bağlamınız için hangisinin en iyi olduğuna karar vermek size kalmış. Onları deneyin ve size kötü kokuyorsa yeniden düzenleme yapın.
Saygılarımla
Asla önemsiz bir 2 satır yönteminin işe yarayacağını varsaymayın. Hızlı bir birim testi yazmak, eksik sıfır testinin, yanlış yerleştirilmiş eksi işaretinin ve / veya ince kapsam hatasının sizi ısırmasını önlemenin tek yoludur, kaçınılmaz olarak bununla şimdi olduğundan daha az zamanınız olduğunda.
"A TRIP" cevabını ikinci olarak veriyorum, ancak testlerin birbirine güvenmesi GEREKİR !!!
Neden?
KURU - Kendini Tekrar Etme - test için de geçerlidir! Test bağımlılıkları 1) kurulum süresinden tasarruf etmenize, 2) fikstür kaynaklarından tasarruf etmenize ve 3) arızaların yerini belirlemenize yardımcı olabilir. Elbette, yalnızca test çerçevenizin birinci sınıf bağımlılıkları desteklediği göz önüne alındığında. Aksi takdirde, kabul ediyorum, kötüler.
Http://www.iam.unibe.ch/~scg/Research/JExample/ adresini takip edin
Genellikle birim testleri, sahte nesneye veya sahte verilere dayanır. Üç tür birim testi yazmayı seviyorum:
Önemli olan, her işlevi test edebilmek için her şeyi yeniden oynatmaktan kaçınmaktır .
Roy Osherove'un Birim Testi Adlandırma standartları tarafından açıklanan tutarlı bir test adlandırma kuralı kullanıyorum Belirli bir test senaryosu sınıfındaki her yöntem aşağıdaki adlandırma stiline sahiptir MethodUnderTest_Scenario_ExpectedResult.
Her bölüm Üst Deve Durumunu kullanır ve bir alt puanla sınırlandırılmıştır.
Testi çalıştırdığımda bunu faydalı buldum, test, test edilen yöntemin adına göre gruplandırılır. Ve bir konvansiyona sahip olmak, diğer geliştiricilerin test amacını anlamasını sağlar.
Ayrıca, test edilen yöntem aşırı yüklenmişse, Yöntem adına parametreler eklerim.