Czy ta nazwa testu znajduje się nieco wyżej?

Question

Jak sugeruje tytuł, czy ta nazwa testu jest tylko odrobiną góry?

WhenChargeIsGreaterThanRestingChargeButLessThanChargeRestApproachStep_OnUpdate_ChargeIsSetToRestingCharge 

Wszelkie sugestie, jak to poprawić? czy jest w porządku tak jak jest?

Poniżej jest cała armatura pomiarowa, gdyż stoi więc można uzyskać pewne kontekst :)

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

Moja osobista opinia jest taka, że ​​nazwy metod nie może być zbyt długi, tak długo jak są one opisowe.

Nazwy testów jednostkowych wydają się być znacznie dłuższe, ponieważ muszą zawierać więcej informacji. Jest to również w porządku dla mnie, ponieważ pojawiają się one tylko w metodzie podpisu i na liście testów (i tam właśnie chcesz mieć dobre imię), nigdy nie wywołasz ich z żadnego innego kodu.

Answer 2

Jednym z popularnych sposobów testowania układu, takich jak te, jest użycie klas zagnieżdżonych ze słownictwem typu Given/When/Then, zgodnie z typowymi praktykami BDD, np.

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

W ten sposób można także zagnieżdżać inne testy, które również pasują do GivenChargeIsGreaterThanRestingCharge fabuła w tym samym miejscu jesteś.

Answer 3

To trochę za długo, opiekunowie chcą przeczytać funkcję, aby szybko zorientować się, co robi funkcja, mając coś na dłużej, co sprawia, że ​​odczytanie samej funkcji staje się szybsze.

Dotyczy to również testów. Kiedy czuję potrzebę napisania esej jako tytuł funkcyjnego strip out „kiedy” „jest” i powtarzające się słowa ... pozostawiając:

ChargeGreaterThanRestingButLessThanRestApproachStep_OnUpdate_ChargeSetToResting

Niewiele mniej opisowe, o wiele bardziej czytelny. ..

jak Windows Phone 7 reklamy powiedzieć „Więcej Glance and Go”

Answer 4

podkreślenia dać wskazówki co do tego, co myślisz, powinny zostać przeniesione z nazwą metody.

• Przenieś testowany przedmiot do nazwy klasy.
• Przenieś wynik testu do instrukcji assert (w razie potrzeby komentarz). Czemu? Jeśli twierdzenie w teście kiedykolwiek się zmienia, czy nazwa testu powinna ulec zmianie?

Wtedy można mieć:

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

Answer 5

Tak na marginesie, w jedną stronę (na pewno nie w jedną stronę) nazywania testów jest napisać swoją nazwę testu jako twierdzenia.

Prosty (naiwne) przykład:

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

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

Na głównym pytaniem myślę nazwy funkcji długo badane są w porządku, tak długo, jak są one jednoznaczne