Birim testi adlandırma en iyi uygulamaları [kapalı]

Birim test sınıflarını ve test yöntemlerini adlandırmak için en iyi uygulamalar nelerdir?

Bu daha önce SO üzerinde tartışıldı, Ünite Testleri için bazı popüler adlandırma kuralları nelerdir?

Bunun çok iyi bir yaklaşım olup olmadığını bilmiyorum, ancak şu anda test projelerimde, her üretim sınıfı ile bir test sınıfı arasında bire bir eşlemelerim var, örn. ProductVe ProductTest.

Test sınıflarımda, test ettiğim yöntemlerin isimleri, alt çizgileri ve daha sonra durum ve ne olmasını beklediğim gibi yöntemlere sahibim Save_ShouldThrowExceptionWithNullName().

Roy Osherove'nin adlandırma stratejisini seviyorum , şu:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

Yöntem adı ve yapılandırılmış bir şekilde gereken her bilgiye sahiptir.

Çalışma birimi tek bir yöntem, bir sınıf veya çok sayıda sınıf kadar büyük olabilir. Bu test durumunda test edilecek ve kontrol altında olan her şeyi temsil etmelidir.

Montajlar .Testsiçin sınıflar için oldukça yaygın ve aynı olduğunu düşündüğüm tipik bir son kullanıyorum (ile biten Tests):

[NameOfTheClassUnderTestTests]

Daha önce Fikstürü Testler yerine sonek olarak kullandım, ancak ikincisinin daha yaygın olduğunu düşünüyorum, sonra adlandırma stratejisini değiştirdim.

Test edilen üniteden (yani sınıf) sonra test fikstürünü adlandırırken testler için "Gerekir" adlandırma standardını takip etmek istiyorum .

Açıklamak için (C # ve NUnit kullanarak):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

Neden "Olmalı" ?

Test yazarlarını sınamayı, "[bir durumda olmalı] [sonra / önce / ne zaman] [eylem gerçekleşir]” satırları boyunca bir cümle olarak adlandırmaya zorladığını görüyorum.

Evet, her yerde “Olmalı” yazmak biraz tekrarlanıyor, ama dediğim gibi yazarları doğru şekilde düşünmeye zorluyor (acemiler için de iyi olabilir). Ayrıca genellikle okunabilir bir İngilizce test adıyla sonuçlanır.

Güncelleme :

Jimmy Bogard'ın da 'olmazsa olmaz' hayranı olduğunu ve bile Should adında bir birim test kütüphanesi olduğunu fark ettim .

Güncelleme (4 yıl sonra ...)

İlgilenenler için, test adlandırma yaklaşımım yıllar içinde gelişti. Yukarıda tanımlamam gereken Should deseniyle ilgili sorunlardan biri, hangi yöntemin test edildiğini bir bakışta bilmek kolay değildir. OOP için test adını test edilen yöntemle başlatmanın daha anlamlı olduğunu düşünüyorum. İyi tasarlanmış bir sınıf için bu, okunabilir test yöntemi adlarıyla sonuçlanmalıdır. Şimdi benzer bir biçim kullanıyorum <method>_Should<expected>_When<condition>. Açıkçası bağlama bağlı olarak gerekir / ne zaman fiil yerine daha uygun bir şey yerine isteyebilirsiniz. Misal: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

Bu adlandırma stilini beğendim:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

ve bunun gibi. Test kullanıcısı olmayan biri için sorunun ne olduğunu gerçekten netleştirir.

Kent Beck şunları öneriyor:

• 'Birim' başına bir test fikstürü (programınızın sınıfı). Test fikstürleri sınıfların kendisidir. Test fikstürünün adı:

  [name of your 'unit']Tests
  

• Test senaryoları (test fikstürü yöntemleri) aşağıdaki gibi isimlere sahiptir:

  test[feature being tested]
  

Örneğin, aşağıdaki sınıfa sahip olanlar:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

Bir test fikstürü:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Sınıf İsimleri . Test fikstürü adları için, "Test" in birçok alanın her yerde her yerde yaygın olduğunu görüyorum. Örneğin, bir mühendislik alanında: StressTestve kozmetik alanında: SkinTest. Kent ile aynı fikirde olmadığım için üzgünüm, ancak test fikstürlerimde "Test" i (StressTestTest ?) kafa karıştırıcı.

"Birim" alan adlarında da çok kullanılır. Örn MeasurementUnit. Bir sınıfa MeasurementUnitTest"Measurement" veya "MeasurementUnit" testi denir mi?

Bu nedenle tüm test sınıflarım için "Qa" önekini kullanmayı seviyorum. ÖrneğinQaSkinTest ve QaMeasurementUnit. Etki alanı nesneleriyle asla karıştırılmaz ve sonek yerine bir önek kullanmak, tüm test fikstürlerinin görsel olarak birlikte yaşadığı anlamına gelir (test projenizde sahte veya diğer destek sınıflarınız varsa yararlıdır)

Ad alanları . C # çalışıyorum ve test sınıfları test ettikleri sınıfla aynı ad alanında tutmak. Ayrı test ad alanlarına sahip olmaktan daha uygundur. Elbette, test sınıfları farklı bir projede.

Test yöntemi adları . Yöntemlerimi WhenXXX_ExpectYYY olarak adlandırmak istiyorum. Ön koşulu netleştirir ve otomatik dokümantasyona (a TestDox) yardımcı olur. Bu, Google test blogundaki tavsiyeye benzer, ancak önkoşul ve beklentilerin daha fazla ayrılmasıyla. Örneğin:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Ben kullanın Verilen-O zaman kavramı. Bu kısa makaleye bir göz atın http://cakebaker.42dh.com/2009/05/28/given-when-then/ . Makale bu kavramı BDD açısından açıklamaktadır, ancak TDD'de de herhangi bir değişiklik yapmadan kullanabilirsiniz.

Bkz. Http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

Test yöntemi adları için, kişisel ve belgelenmiş isimleri çok yararlı buluyorum (testin ne yaptığını daha fazla açıklayan Javadoc yorumlarının yanında).

En önemli şeylerden birinin adlandırma sözleşmenizde tutarlı olduğunu düşünüyorum (ve ekibinizin diğer üyeleriyle aynı fikirdeyim). Birçok kez aynı projede birçok farklı konvansiyon kullanıldığını görüyorum.

Kısa bir süre önce, tanımlamaları en üst düzeye çıkarmak için testlerimi, sınıflarını ve projelerini adlandırmak için aşağıdaki sözleşmeyi yaptım:

Diyelim ki Settingssınıfı MyApp.Serializationisim alanındaki bir projede test ediyorum .

İlk olarak, MyApp.Serialization.Testsad alanı ile bir test projesi oluşturacağım .

Bu proje içinde ve tabii ki isim alanında IfSettings( IfSettings.cs olarak kaydedilmiş ) adında bir sınıf oluşturacağım .

Diyelim ki SaveStrings()yöntemi test ediyorum . -> Testi adlandıracağım CanSaveStrings().

Bu testi çalıştırdığımda şu başlığı gösterecektir:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

Bence bu çok iyi anlatıyor, ne test ediyor.

Tabii ki İngilizce'de "Testler" isminin "testler" fiili ile aynı olması yararlıdır.

Testleri adlandırırken yaratıcılığınızın bir sınırı yoktur, böylece onlar için tam cümle başlıkları alırız.

Genellikle Test isimlerinin bir fiil ile başlaması gerekir.

Örnekler:

• Algılar (ör. DetectsInvalidUserInput)
• Atar (ör. ThrowsOnNotFound)
• Will (örneğin WillCloseTheDatabaseAfterTheTransaction)

vb.

Başka bir seçenek de "if" yerine "that" kullanmaktır.

İkincisi Bana rağmen tuş vuruşlarını ve ben bilmiyorum çünkü, ne yapıyorum daha tam olarak tarif eder kaydeder olduğunu test davranış mevcut olmakla birlikte, test ediyorum eğer öyle.

[ Düzenle ]

Yukarıdaki adlandırma kuralını biraz daha uzun süre kullandıktan sonra , arayüzlerle çalışırken If önekinin kafa karıştırıcı olabileceğini buldum . Öyle ki, IfSerializer.cs test sınıfı "Open Files Sekmesi" ndeki ISerializer.cs arayüzüne çok benziyor . Bu, testler, test edilen sınıf ve arayüzü arasında ileri geri geçiş yaparken çok can sıkıcı olabilir. Sonuç olarak ben şimdi seçsin Yani üzerinde If önek olarak.

Ayrıca şimdi - sadece test sınıflarımdaki yöntemler için başka hiçbir yerde en iyi uygulama olarak kabul edilmez - "_" benim gibi test yöntemi adları kelime ayırmak için kullanın:

[Test] public void detects_invalid_User_Input()

Bunu okumayı daha kolay buluyorum.

[ Düzenlemeyi Sonlandır ]

Umarım bu daha fazla fikir ortaya çıkarır, çünkü testlerin ne yaptığını anlamaya çalışmak için harcanan çok fazla zaman kazandırabileceği için büyük önem taşıyan testleri adlandırmayı düşünürüm (örneğin, genişletilmiş bir aradan sonra bir projeye devam ettikten sonra) .

VS + NUnit'te genellikle fonksiyonel testleri birlikte gruplandırmak için projemde klasörler oluştururum. Sonra birim test fikstür sınıfları oluşturmak ve bunları test ediyorum işlevsellik türü sonra adlandırın. [Test] yöntemleri şu satırlarda adlandırılır Can_add_user_to_domain:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

Testlerinizi aynı pakette ancak test edilen kaynağa paralel bir dizinde tutmanın, bir sürü dışlama deseni yapmak zorunda kalmadan konuşlandırmaya hazır olduğunuzda kodun şişmesini ortadan kaldırdığını eklemeliyim.

Şahsen "JUnit Pocket Guide" da açıklanan en iyi uygulamaları seviyorum ... JUnit'in ortak yazarı tarafından yazılmış bir kitabı yenmek zor!

Foo sınıfı için test senaryosunun adı FooTestCase veya bunun gibi bir şey olmalıdır (FooIntegrationTestCase veya FooAcceptanceTestCase) - çünkü bir test vakasıdır. test, test durumu, test fikstürü, test yöntemi vb. gibi bazı standart adlandırma kuralları için http://xunitpatterns.com/ adresine bakın .