Questo nome del test è un po 'esagerato

Question

Come suggerisce il titolo, questo nome del test è solo un po' tra i migliori?

WhenChargeIsGreaterThanRestingChargeButLessThanChargeRestApproachStep_OnUpdate_ChargeIsSetToRestingCharge 

Qualche suggerimento su come migliorare questo? o va bene così com'è?

Di seguito si riporta l'intero dispositivo di prova così com'è in modo da poter ottenere un certo contesto :)

public class NeuronTests  
{ 
     [Fact] 
     public void OnUpdate_NeuronFiresWhenChargeIsEqualToThreshold() 
     { 
      Neuron neuron = new Neuron(); 
      bool fired = false; 
      neuron.Fired += (s, e) => fired = true; 
      neuron.Charge = Neuron.ChargeThreshold; 

      neuron.Update(); 

      Assert.True(fired, "Neuron didn't fire"); 
     } 

     [Fact] 
     public void OnUpdate_NeuronDoesntFireWhenChargeIsLessThanThreshold() 
     { 
      Neuron neuron = new Neuron(); 
      bool fired = false; 
      neuron.Fired += (s, e) => fired = true; 

      neuron.Charge = Neuron.ChargeThreshold - 1f; 
      neuron.Update(); 

      Assert.False(fired, "Neuron fired!"); 
     } 

     [Fact] 
     public void OnUpdate_NeuronFiresWhenChargeIsGreaterThanThreshold() 
     { 
      Neuron neuron = new Neuron(); 
      bool fired = false; 
      neuron.Fired += (s, e) => fired = true; 
      neuron.Charge = Neuron.ChargeThreshold + 1f; 

      neuron.Update(); 

      Assert.True(fired, "Neuron didn't fire"); 
     } 

     [Fact] 
     public void WhenNeuronFires_ChargeResetsToRestingCharge() 
     { 
      Neuron neuron = new Neuron(); 
      neuron.Charge = Neuron.ChargeThreshold; 

      neuron.Update(); 

      Assert.Equal(Neuron.RestingCharge, neuron.Charge); 
     } 

     [Fact] 
     public void AfterFiring_OnUpdate_NeuronWontFire() 
     { 
      Neuron neuron = new Neuron(); 
      int fireCount = 0; 
      neuron.Fired += (s, e) => fireCount++; 

      neuron.Charge = Neuron.ChargeThreshold; 
      neuron.Update(); 
      neuron.Charge = Neuron.ChargeThreshold; 
      neuron.Update(); 

      Assert.Equal(1, fireCount); 
     } 

     [Fact] 
     public void WhenResting_OnUpdate_NeuronWillFire() 
     { 
      Neuron neuron = new Neuron(); 
      int fireCount = 0; 
      neuron.Fired += (s, e) => fireCount++; 

      neuron.Charge = Neuron.ChargeThreshold; 
      neuron.Update(); 
      neuron.Charge = Neuron.ChargeThreshold; 
      neuron.Update(); 
      neuron.Charge = Neuron.ChargeThreshold; 
      neuron.Update(); 

      Assert.Equal(2, fireCount); 
     } 

     [Fact] 
     public void WhenChargeIsGreaterThanRestingCharge_OnUpdate_ChargeDecreasesTowardsRestingCharge() 
     { 
      Neuron neuron = new Neuron(); 

      neuron.Charge = Neuron.RestingCharge + (2 * Neuron.ChargeRestApproachStep); 

      neuron.Update(); 

      Assert.Equal(Neuron.RestingCharge + Neuron.ChargeRestApproachStep, neuron.Charge); 
     } 

     [Fact] 
     public void WhenChargeIsGreaterThanRestingChargeButLessThanChargeRestApproachStep_OnUpdate_ChargeIsSetToRestingCharge() 
     { 
      Neuron neuron = new Neuron(); 

      neuron.Charge = Neuron.RestingCharge + (Neuron.ChargeRestApproachStep * 0.5f); 

      neuron.Update(); 

      Assert.Equal(Neuron.RestingCharge, neuron.Charge); 
     } 


    } 

Answer 1

La mia opinione personale è che i nomi dei metodi non possono mai essere troppo lungo, fintanto che sono descrittivi.

I nomi dei test di unità tendono ad essere molto più lunghi, poiché devono contenere più informazioni. Questo va bene anche per me, dal momento che appaiono solo nella firma del metodo e nella tua lista di test (e questo è dove vuoi avere un buon nome), non li chiamerai mai da nessun altro codice.

Answer 2

Un metodo popolare per test di layout come questi consiste nell'utilizzare classi nidificate con un vocabolario Given/When/Then come suggerito dalle pratiche BDD tipiche, ad es.

public class NeuronStory 
{ 
    public class GivenChargeIsGreaterThanRestingCharge 
    { 
     public class GivenChargeIsLessThanChargeRestApproachStep 
     { 
      public class WhenUpdated 
      { 
       public void ThenChargeIsSetToRestingCharge() 
       { 
       } 
      } 
     } 
    } 
} 

In questo modo è anche possibile nidificare gli altri test che si inseriscono anche nella GivenChargeIsGreaterThanRestingCharge trama nello stesso luogo.

Answer 3

È un po 'lungo, i manutentori vogliono leggere la funzione per avere un'idea veloce di ciò che fa la funzione, avendo qualcosa che a lungo rende più veloce la lettura della funzione stessa.

Questo vale anche per i test. Quando sento il bisogno di scrivere un saggio come un titolo di funzione, che striscia fuori 'quando' 'è' e le parole ripetute ... lasciando:

ChargeGreaterThanRestingButLessThanRestApproachStep_OnUpdate_ChargeSetToResting

Non molto meno descrittivo, molto più facilmente leggibile. ..

Come I Windows Phone 7 annunci dire 'occhiata and Go'

Answer 4

le sottolineature dare indizi di ciò che si pensa dovrebbe essere spostato fuori il nome del metodo.

• Sposta ciò che è sotto test al nome della classe.
• Sposta quale dovrebbe essere il risultato del test sull'asserzione (commento se necessario). Perché? Se l'asserzione nel test cambia mai, il nome del test dovrebbe cambiare?

Poi si potrebbe avere:

public class NeuronOnUpdateTests 
{ 
    public void WhenChargeIsBetweenRestingChargeAndChargeRestApproachStep 
    { 
    //Charge is set to resting state 
    Assert.True(x); 
    } 
} 

Answer 5

Per inciso, in un modo (non certo il solo andata) di nominare test è quello di scrivere il nome del test come asserzione.

Un semplice (naive) Esempio:

int Add(object a, object b) 
{ 
    return a+b; 
} 

[TestMethod] 
void AddFailsWithNonIntegerArguments() 
{ 
    try 
    { 
     Add("Hello", "World"); 
     Assert::Fail(); 
    } 
    catch 
    { 
     Assert::Pass(); 
    } 
} 

Sulla questione principale credo che i nomi delle funzioni lungo test vanno bene, purché siano inequivocabili