Le migliori pratiche per denominare unità e metodi di test di integrazione?

Question

Ho recentemente ereditato un'applicazione scritta da persone diverse in momenti diversi e cercando indicazioni su come standardizzare.

Answer 1

Assumendo NUnit:

[Test] 
public void ObjectUnderTest_StateChanged_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void ObjectUnderTest_Behaviour_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

ad esempio:

[Test] 
public void WifeIsTired_TakeWifeToDinner_WifeIsGrateful() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void WifeIsTired_MentionNewGirlfriend_WifeGetsHalf() 
{ 
    Assert.That(tra_la_la); 
} 

Answer 2

Ho trovato due buoni suggerimenti. Puntano qui: http://slott-softwarearchitect.blogspot.com/2009/10/unit-test-naming.html

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

http://openmrs.org/wiki/Unit_Testing_with_@should

Answer 3

in quella situazione probabilmente sarei trovato la convenzione di denominazione che è stato utilizzato di più e refactoring il resto del codice di utilizzare tale. Se quello che è stato usato di più è veramente orribile, guarderei ancora al codice esistente e cerco di trovarne uno con cui potrei convivere. La coerenza è più importante delle convenzioni arbitrarie.

Answer 4

Uso un costrutto FunctionTestCondition. Se ho due metodi, Get e Set avrei forse creare i seguenti metodi di prova:

• GetTest essendo un test positivo (tutto è ok).
• GetTestInvalidIndex per verificare un indice non valido passato al metodo.
• GetTestNotInitialized per verificare quando i dati non sono inseriti prima dell'uso.
• SetTest
• SetTestInvalidIndex
• SetTestTooLargeValue
• SetTestTooLongString

Answer 5

E 'istruttivo osservare BDD (sviluppo guidato comportamentale) e this blog post in particolare.

BDD si concentra essenzialmente sui componenti e su ciò che fanno do do. Di conseguenza, influisce direttamente sul nome/sulla struttura dei test e sul codice che usano per impostare le condizioni e convalidare. BDD consente non solo agli sviluppatori di leggere/scrivere i test, ma i membri non tecnici del team (analisti aziendali ecc.) Possono contribuire specificando i test e convalidandoli.

Answer 6

Ho appena scritto a cosa serve. Non è che dovrai digitare i nomi in nessun altro, quindi avere un testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator non è un problema. Tutto ciò che è un test inizia con "test", ovviamente.

Answer 7

Raggruppare i test per impostazione, effettuare una classe di test intorno a questa configurazione e il nome è con suffisso Test o IntegrationTest. Utilizzando un framework di test come JUnit o TestNG, è possibile assegnare un nome ai metodi di test desiderati. Chiamerei il metodo come test, una frase in un caso di cammello, non un prefisso di prova. I framework utilizzano un'annotazione @Test per contrassegnare un metodo come test.

Answer 8

Non esiste uno standard, come tali, persone diverse/posti avranno diversi regimi.L'importante è che tu sia stick ad uno standard.

Personalmente sono un fan delle seguenti - codice di esempio in C#, ma molto vicino a Java, applico stesse regole:

[Test] 
public void person_should_say_hello() 
{ 
    // Arrange 
    var person = new Person(); 
    // Act 
    string result = person.SayHello(); 
    // Assert 
    Assert(..., "The person did not say hello correctly!"); 
} 

esplicita

Il nome del test dovrebbe dare il nome della classe in esame In questo esempio, la classe sottoposta a test è Person. Il nome del test dovrebbe avere anche il nome del metodo che viene testato. In questo modo, se il test dovesse fallire, saprai almeno dove cercare di risolverlo. Ti suggerisco inoltre di seguire la regola AAA - Arrange, Act, Assert, per garantire che i tuoi test siano facili da leggere e seguire.

amichevole non riescono messaggi

Quando si tratta di affermare un risultato/Stato, il suo utile includere un messaggio opzionale. Ciò rende più semplice quando un test fallisce, specialmente quando viene eseguito come parte di un processo di compilazione o tramite uno strumento esterno.

sottolinea

La finale (anche se opzionale) presa di posizione Seguo sta utilizzando sottolineatura per i nomi di test. Anche se non sono un fan dei caratteri di sottolineatura nel codice di produzione, il loro uso nei nomi dei test è utile in quanto i nomi dei test sono spesso molto più lunghi. Il rapido controllo del nome di un test che utilizza i caratteri di sottolineatura risulta essere molto più leggibile, sebbene questo sia soggettivo e fonte di molti dibattiti in merito alle pratiche di test unitario.

Integration Test

applicare gli stessi standard di test di integrazione, l'unica differenza essendo la posizione di tali test dovrebbero essere separato dal test di unità. Nel codice di esempio sopra, la classe di test si chiamerebbe PersonTests e si trova in un file chiamato PersonTests.cs. I test di integrazione dovrebbero essere denominati in modo simile: PersonIntegrationTests, che si trova in PersonIntegrationTests.cs. Lo stesso progetto può essere utilizzato per questi test, ma assicurarsi che si trovino in directory separate.