Quali sono alcune convenzioni di denominazione popolari per i test unitari? [chiuso]

Generale

• Seguire gli stessi standard per tutti i test.
• Sii chiaro su quale sia lo stato di ciascun test.
• Sii specifico sul comportamento previsto.

Esempi

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Fonte: standard di denominazione per i test unitari

2) Separare ogni parola per Underscore

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

Altro

• Termina i nomi dei metodi con Test
• Inizia i nomi dei metodi con il nome della classe

Sono praticamente con te su questo uomo. Le convenzioni di denominazione che hai usato sono:

• Chiaro su quale sia ogni stato del test.
• Specifico sul comportamento previsto.

Cosa ti serve di più dal nome di un test?

Contrariamente alla risposta di Ray, non credo sia necessario il prefisso Test . È un codice di prova, lo sappiamo. Se è necessario eseguire questa operazione per identificare il codice, quindi si verificano problemi maggiori, il codice di test non deve essere confuso con il codice di produzione.

Per quanto riguarda la lunghezza e l'uso del trattino basso, il suo codice di prova , a chi diavolo importa? Solo tu e il tuo team lo vedrete, finché sarà leggibile e chiaro su cosa sta facendo il test, continuate! :)

Detto questo, sono ancora abbastanza nuovo nel testare e bloggare le mie avventure con esso :)

Vale anche la pena leggere: Test di unità strutturanti

La struttura ha una classe di test per classe in fase di test. Non è così insolito. Ma ciò che era insolito per me era che aveva una classe nidificata per ogni metodo testato.

per esempio

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

Ed ecco perché:

Bene, per prima cosa, è un bel modo di organizzare i test. Tutti i test (o fatti) per un metodo sono raggruppati insieme. Ad esempio, se si utilizza il collegamento CTRL + M, CTRL + O per comprimere i corpi del metodo, è possibile eseguire facilmente la scansione dei test e leggerli come una specifica per il codice.

Mi piace anche questo approccio:

MethodName_StateUnderTest_ExpectedBehavior

Quindi forse adeguati a:

StateUnderTest_ExpectedBehavior

Perché ogni test sarà già in una classe nidificata

Tendo ad usare la convenzione di MethodName_DoesWhat_WhenTheseConditionscosì per esempio:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Tuttavia, ciò che vedo molto è far sì che il nome del test segua la struttura di test unitaria di

• Organizzare
• atto
• Asserire

Che segue anche la sintassi BDD / Gherkin di:

• Dato
• quando
• Poi

quale sarebbe nominare la prova nel modo di: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

quindi al tuo esempio:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Tuttavia preferisco di gran lunga mettere prima il nome del metodo da testare, perché in seguito i test possono essere disposti in ordine alfabetico o visualizzati in ordine alfabetico nella casella a discesa dei membri in VisStudio e tutti i test per 1 metodo sono raggruppati insieme.

In ogni caso, mi piace separare le sezioni principali del nome del test con caratteri di sottolineatura, al contrario di ogni parola , perché penso che faciliti la lettura e la comprensione del test.

In altre parole, mi piace: Sum_ThrowsException_WhenNegativeNumberAs1stParammeglio di Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Noto i miei metodi di prova come altri metodi usando "PascalCasing" senza sottolineature o separatori. Lascio il test postfix per il metodo fuori, perché non aggiunge alcun valore. Che il metodo sia un metodo di prova è indicato dall'attributo TestMethod .

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

A causa del fatto che ogni classe Test dovrebbe testare solo un'altra classe, lascio il nome della classe fuori dal nome del metodo. Il nome della classe che contiene i metodi di test è chiamato come la classe sotto test con il postfix "Test".

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

Per i metodi che verificano eccezioni o azioni che non sono possibili, ho il prefisso del metodo di prova con la parola Cannot .

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

Le mie convinzioni sui nomi si basano sull'articolo "Suggerimenti TDD: test delle convenzioni e linee guida sui nomi" di Bryan Cook. Ho trovato questo articolo molto utile.

La prima serie di nomi è più leggibile per me, dal momento che CamelCasing separa le parole e le barre inferiori separano parti dello schema di denominazione.

Tendo anche a includere "Test" da qualche parte, nel nome della funzione o nello spazio dei nomi o nella classe che lo racchiude.

Fintanto che segui una singola pratica, non importa davvero. In genere, scrivo un test unitario singolo per un metodo che copre tutte le varianti di un metodo (ho metodi semplici;) e quindi scrivo set di test più complessi per i metodi che lo richiedono. La mia struttura di denominazione è quindi di solito test (un holdover da JUnit 3).

Uso un prefisso "T" per testare spazi dei nomi, classi e metodi.

Cerco di essere pulito e creare cartelle che replicano gli spazi dei nomi, quindi creare una cartella di test o un progetto separato per i test e replicare la struttura di produzione per i test di base:

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

Posso facilmente vedere che qualcosa è un test, so esattamente a quale codice originale appartiene (se non riesci a risolverlo, il test è comunque troppo contorto).

Sembra proprio la convenzione di denominazione delle interfacce, (voglio dire, non ti confondi con le cose che iniziano con 'I', né lo farai con 'T').

È facile compilare con o senza i test.

In teoria è comunque buono e funziona abbastanza bene per piccoli progetti.