Best practice per la denominazione di unit test [chiuso]

Quali sono le migliori pratiche per la denominazione di classi di test unit e metodi di test?

Questo è stato discusso su SO prima, in Quali sono alcune convenzioni di denominazione popolari per i test unitari?

Non so se si tratta di un approccio molto valido, ma attualmente nei miei progetti di test ho mappature one-to-one tra ciascuna classe di produzione e una classe di test, ad esempio Producte ProductTest.

Nelle mie classi di test ho quindi metodi con i nomi dei metodi che sto testando, un trattino basso, quindi la situazione e ciò che mi aspetto che accada, ad es Save_ShouldThrowExceptionWithNullName().

Mi piace la strategia di denominazione di Roy Osherove , è la seguente:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

Ha tutte le informazioni necessarie sul nome del metodo e in modo strutturato.

L'unità di lavoro può essere piccola come un singolo metodo, una classe o grande come più classi. Dovrebbe rappresentare tutte le cose che devono essere testate in questo caso di test e che sono sotto controllo.

Per gli assiemi uso il .Testsfinale tipico , che penso sia abbastanza diffuso e lo stesso per le classi (che termina con Tests):

[NameOfTheClassUnderTestTests]

In precedenza ho usato Fixture come suffisso anziché Test, ma penso che quest'ultimo sia più comune, quindi ho cambiato la strategia di denominazione.

Mi piace seguire lo standard di denominazione "Dovrebbe" per i test mentre nomina l' apparecchiatura di test dopo l'unità sotto test (cioè la classe).

Per illustrare (usando C # e NUnit):

[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));
  }
}

Perché "dovrebbe" ?

Trovo che costringe gli autori del test a nominare il test con una frase lungo le righe di "Dovrebbe [essere in qualche stato] [dopo / prima / quando] [l'azione ha luogo]"

Sì, scrivere "Dovrei" ovunque diventa un po 'ripetitivo, ma come ho detto costringe gli scrittori a pensare nel modo corretto (quindi può essere buono per i principianti). Inoltre, in genere si ottiene un nome test inglese leggibile.

Aggiornamento :

Ho notato che Jimmy Bogard è anche un fan di "should" e ha persino una libreria di test unitari chiamata Should .

Aggiornamento (4 anni dopo ...)

Per coloro che sono interessati, il mio approccio ai test di denominazione si è evoluto nel corso degli anni. Uno dei problemi con il modello Should che ho descritto sopra non è facile sapere a colpo d'occhio quale metodo è in fase di test. Per OOP penso che abbia più senso iniziare il nome del test con il metodo in esame. Per una classe ben progettata ciò dovrebbe tradursi in nomi di metodi di prova leggibili. Ora uso un formato simile a <method>_Should<expected>_When<condition>. Ovviamente, a seconda del contesto, potresti voler sostituire i verbi Should / When con qualcosa di più appropriato. Esempio: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

Mi piace questo stile di denominazione:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

e così via. Rende davvero chiaro a un non tester quale sia il problema.

Kent Beck suggerisce:

• Un dispositivo di prova per "unità" (classe del programma). Le apparecchiature di prova sono le classi stesse. Il nome del dispositivo di prova dovrebbe essere:

  [name of your 'unit']Tests
  

• I casi di test (i metodi del dispositivo di prova) hanno nomi come:

  test[feature being tested]
  

Ad esempio, con la seguente classe:

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

    // other methods and properties
}

Un dispositivo di prova sarebbe:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Nomi delle classi . Per i nomi dei dispositivi di prova, trovo che "Test" sia abbastanza comune nel linguaggio onnipresente di molti domini. Ad esempio, in un dominio di ingegneria: StressTeste in un dominio cosmetici: SkinTest. Mi dispiace non essere d'accordo con Kent, ma usare "Test" nei miei dispositivi di prova ( StressTestTest?) È confuso.

"Unità" è anche molto usata nei domini. Es MeasurementUnit. Una classe è chiamata MeasurementUnitTesttest di "Measurement" o "MeasurementUnit"?

Pertanto mi piace usare il prefisso "Qa" per tutte le mie classi di test. Ad esempio, QaSkinTeste QaMeasurementUnit. Non viene mai confuso con gli oggetti di dominio e l'utilizzo di un prefisso anziché di un suffisso significa che tutte le apparecchiature di test convivono visivamente (utile se nel progetto di test sono presenti falsi o altre classi di supporto)

Spazi dei nomi . Lavoro in C # e mantengo le mie classi di test nello stesso spazio dei nomi della classe che stanno testando. È più conveniente che avere spazi dei nomi di prova separati. Naturalmente, le classi di test fanno parte di un progetto diverso.

Nomi dei metodi di prova . Mi piace nominare i miei metodi WhenXXX_ExpectYYY. Rende chiara la precondizione e aiuta con la documentazione automatizzata (alla TestDox). Questo è simile ai consigli sul blog di test di Google, ma con una maggiore separazione di condizioni e aspettative. Per esempio:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Uso il concetto Given-When-Then . Dai un'occhiata a questo breve articolo http://cakebaker.42dh.com/2009/05/28/given-when-then/ . L'articolo descrive questo concetto in termini di BDD, ma è possibile utilizzarlo anche in TDD senza alcuna modifica.

Vedi: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

Per i nomi dei metodi di prova, trovo personalmente molto utile l'uso di nomi dettagliati e autodocumentati (insieme ai commenti Javadoc che spiegano ulteriormente cosa sta facendo il test).

Penso che una delle cose più importanti sia quella di essere coerenti nella tua convenzione di denominazione (e concordarla con gli altri membri della tua squadra). Molte volte vedo un sacco di convenzioni diverse utilizzate nello stesso progetto.

Di recente ho escogitato la seguente convenzione per nominare i miei test, le loro classi e contenere i progetti al fine di massimizzarne le descrizioni:

Diciamo che sto testando la Settingsclasse in un progetto nello MyApp.Serializationspazio dei nomi.

Per prima cosa creerò un progetto di test con lo MyApp.Serialization.Testsspazio dei nomi.

All'interno di questo progetto e ovviamente lo spazio dei nomi creerò una classe chiamata IfSettings(salvata come IfSettings.cs ).

Diciamo che sto testando il SaveStrings()metodo. -> Chiamerò il test CanSaveStrings().

Quando eseguo questo test mostrerà la seguente intestazione:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

Penso che questo mi dica molto bene, cosa sta testando.

Naturalmente è utile che in inglese il nome "Test" sia lo stesso del verbo "test".

Non c'è limite alla tua creatività nel nominare i test, in modo da ottenere titoli completi per loro.

Di solito i nomi dei test dovranno iniziare con un verbo.

Esempi inclusi:

• Rileva (ad es. DetectsInvalidUserInput)
• Lancia (es. ThrowsOnNotFound)
• Volontà (ad es. WillCloseTheDatabaseAfterTheTransaction)

eccetera.

Un'altra opzione è quella di utilizzare "that" invece di "if".

Quest'ultimo però mi salva la pressione dei tasti e descrive più esattamente cosa sto facendo, poiché non lo so, che il comportamento testato è presente, ma sto testando se lo è.

[ Modifica ]

Dopo aver usato la convenzione di denominazione sopra per un po 'di più, ho scoperto che il prefisso If può essere fonte di confusione, quando si lavora con le interfacce. Accade semplicemente che la classe di test IfSerializer.cs sia molto simile all'interfaccia ISerializer.cs nella "Scheda File aperti". Questo può diventare molto fastidioso quando si passa avanti e indietro tra i test, la classe in fase di test e la sua interfaccia. Di conseguenza ora sceglierei Quello su Se come prefisso.

Inoltre ora uso - solo per i metodi nelle mie classi di test in quanto non è considerata la migliore pratica altrove - il "_" per separare le parole nei nomi dei miei metodi di prova come in:

[Test] public void detects_invalid_User_Input()

Trovo che sia più facile da leggere.

[ Fine modifica ]

Spero che questo generi altre idee, dal momento che considero test di denominazione di grande importanza in quanto può farti risparmiare un sacco di tempo che altrimenti sarebbe stato speso cercando di capire cosa stanno facendo i test (ad esempio dopo aver ripreso un progetto dopo una pausa prolungata) .

In VS + NUnit di solito creo cartelle nel mio progetto per raggruppare test funzionali. Quindi creo le classi di dispositivi di unit test e le denomino in base al tipo di funzionalità che sto testando. I metodi [Test] sono denominati secondo le linee di 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

Dovrei aggiungere che il mantenimento dei test nello stesso pacchetto, ma in una directory parallela alla sorgente in fase di test, elimina il gonfiore del codice una volta che sei pronto a distribuirlo senza dover fare un mucchio di schemi di esclusione.

Personalmente mi piacciono le migliori pratiche descritte nella "Guida tascabile di JUnit" ... è difficile battere un libro scritto dal coautore di JUnit!

il nome del test case per la classe Foo dovrebbe essere FooTestCase o qualcosa del genere (FooIntegrationTestCase o FooAcceptanceTestCase), poiché si tratta di un caso di test. consultare http://xunitpatterns.com/ per alcune convenzioni di denominazione standard come test, caso di test, dispositivo di test, metodo di test, ecc.