¿Es este nombre de prueba un poco exagerado?

Question

Como sugiere el título, ¿el nombre de esta prueba es solo un poco de la parte superior?

WhenChargeIsGreaterThanRestingChargeButLessThanChargeRestApproachStep_OnUpdate_ChargeIsSetToRestingCharge 

¿Alguna sugerencia sobre cómo mejorar esto? o está bien como es?

A continuación se muestra todo el conjunto de prueba tal y como está para que pueda obtener algo de contexto :)

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

Mi opinión personal es que los nombres de métodos no pueden ser nunca demasiado tiempo, siempre y cuando sean descriptivos.

Los nombres de las pruebas unitarias tienden a ser mucho más largos, ya que deben contener más información. Esto también está bien para mí, ya que solo aparecen en la firma del método y en su lista de pruebas (y aquí es donde desea tener un buen nombre), nunca las llamará desde ningún otro código.

Answer 2

Una forma popular de realizar pruebas de diseño como estas es utilizar clases anidadas con un tipo de vocabulario Given/When/Then tal como lo sugieren las prácticas típicas de BDD, p. Ej.

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

De esta manera También puede anidar otras pruebas que también encajan en la historia GivenChargeIsGreaterThanRestingCharge en el mismo lugar.

Answer 3

Es un poco largo, los mantenedores quieren leer la función para tener una idea rápida de lo que hace la función, teniendo algo que hace que sea más rápido leer la función en sí.

Esto se aplica también a las pruebas. Cuando siento la necesidad de escribir un ensayo como un título de la función, me tira hacia fuera 'cuando' 'es' y palabras repetidas ... dejando:

ChargeGreaterThanRestingButLessThanRestApproachStep_OnUpdate_ChargeSetToResting

No mucho menos descriptivo, mucho más fácil de leer. ..

Como el teléfono de Windows 7 Anuncios dicen 'Más vistazo and Go'

Answer 4

los guiones dan pistas sobre lo que cree que debería ser trasladado fuera del nombre del método.

• Mueva lo que está bajo prueba al nombre de clase.
• Mueva el resultado de la prueba a la declaración de confirmación (comente si es necesario). ¿Por qué? Si la afirmación en la prueba cambia alguna vez, ¿debería cambiar el nombre de la prueba?

entonces usted podría tener:

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

Answer 5

Dicho sea de paso, de una manera (ciertamente no el único camino) de nombrar pruebas es escribir su nombre de la prueba como una afirmación.

Un simple (naive) ejemplo:

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

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

Sobre la cuestión principal Creo nombres de función a largo de la prueba son muy bien, siempre y cuando sean inequívocos