Quali sono alcune convenzioni di denominazione popolari per gli unit test?[Chiuso]

Question

Generale

• Seguire gli stessi standard per tutti i test.
• Sii chiaro su cosa sia ogni stato del test.
• Sii specifico riguardo al comportamento previsto.

Esempi

1) NomeMetodo_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 tramite un carattere di sottolineatura

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

Answer 1

Sono praticamente con te su quest'uomo.Le convenzioni di denominazione che hai utilizzato sono:

• Chiarire qual è lo stato di ogni test.
• Specifico sul comportamento previsto.

Cos'altro ti serve da un nome di prova?

Contrario a La risposta di Ray Non penso che Test il prefisso è necessario.È un codice di prova, lo sappiamo.Se devi farlo per identificare il codice, allora hai problemi più grandi, il tuo codice di test non deve essere confuso con il codice di produzione.

Per quanto riguarda la lunghezza e l'uso del carattere di sottolineatura, è codice di prova, chi diavolo se ne frega?Solo tu e il tuo team lo vedrete, purché sia ​​leggibile e chiaro su cosa sta facendo il test, continuate!:)

Detto questo, sono ancora abbastanza nuovo nei test e bloggando le mie avventure con esso :)

Answer 2

Vale la pena leggere anche questo: Strutturazione dei test unitari

La struttura ha una classe di test per ogni classe in fase di test.Non è così insolito.Ma ciò che era insolito per me era che avesse una classe annidata 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é:

Beh, per prima cosa, è un bel modo per mantenere i test organizzati.Tutti i test (o i fatti) per un metodo sono raggruppati insieme.Ad esempio, se si utilizza il collegamento CTRL+M, CTRL+O per crollare i corpi del metodo, puoi facilmente scansionare i test e leggerli come una specifica per il tuo codice.

Mi piace anche questo approccio:

NomeMetodo_StateUnderTest_ExpectedBehavior

Quindi forse adattati a:

StateUnderTest_ExpectedBehavior

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

Answer 3

Tendo a usare la convenzione di MethodName_DoesWhat_WhenTheseConditions quindi ad esempio:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Tuttavia, quello che vedo spesso è fare in modo che il nome del test segua la struttura dei test unitari di

• Organizzare
• Atto
• Affermare

Che segue anche la sintassi BDD/Gherkin di:

• Dato
• Quando
• Poi

che significherebbe nominare il test nel modo di: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

quindi al tuo esempio:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Tuttavia preferisco di gran lunga inserire prima il nome del metodo da testare, perché in questo modo i test possono essere organizzati in ordine alfabetico o apparire ordinati alfabeticamente nella casella a discesa dei membri in VisStudio e tutti i test per 1 metodo sono raggruppati insieme.

---

In ogni caso, mi piace separare i maggiori sezioni del nome del test con trattini bassi, al contrario di ogni parola, perché penso che renda più facile leggere e far capire il senso del test.

In altre parole, mi piace: Sum_ThrowsException_WhenNegativeNumberAs1stParam meglio di Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Answer 4

Nomino i miei metodi di test come altri metodi che utilizzano "PascalCasing" senza caratteri di sottolineatura o separatori.Lascio il suffisso Test per il metodo out, perché non aggiunge alcun valore.Che il metodo sia un metodo di prova è indicato dall'attributo Metodo di prova.

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

Dato 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 è denominato come la classe sotto test con il suffisso "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, antepongo il metodo di test con la parola Non può.

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

La mia convenzione di denominazione si basa sull'articolo "Suggerimenti per il TDD:Convenzioni e linee guida per la denominazione dei test" di Bryan Cook.Ho trovato questo articolo molto utile.

Answer 5

La prima serie di nomi è più leggibile per me, poiché CamelCasing separa le parole e le barre inferiori separano le 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 la racchiude.

Answer 6

Finché segui una singola pratica, non ha molta importanza.In genere, scrivo un singolo unit test per un metodo che copre tutte le variazioni di un metodo (ho metodi semplici;) e quindi scrivo set di test più complessi per i metodi che lo richiedono.La mia struttura dei nomi è quindi solitamente di prova (un residuo di JUnit 3).

Answer 7

Utilizzo il prefisso "T" per spazi dei nomi, classi e metodi di test.

Cerco di essere pulito e creare cartelle che replichino 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 si riferisce (se non riesci a capirlo, il test è comunque troppo contorto).

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

È facile compilare semplicemente con o senza i test.

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