Ist dieser Test Name nur ein bisschen über den oberen

Question

Wie der Titel schon vermuten lässt, ist dieser Test Name nur ein wenig von der Spitze?

WhenChargeIsGreaterThanRestingChargeButLessThanChargeRestApproachStep_OnUpdate_ChargeIsSetToRestingCharge 

Irgendwelche Vorschläge, wie man das verbessert? oder ist es gut so wie es ist?

Unten ist die gesamte Testvorrichtung, wie es steht, so können Sie einige Kontext bekommen :)

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

Meine persönliche Meinung ist, dass Methodennamen kann nie zu lang sein, solange sie beschreibend sind.

Unit-Test-Namen sind in der Regel viel länger sein, da sie mehr Informationen enthalten. Dies ist auch für mich in Ordnung, da sie nur in der Methodensignatur und in der Liste der Tests angezeigt werden (und hier möchten Sie einen guten Namen haben), Sie werden sie nie von einem anderen Code aus aufrufen.

Answer 2

Ein beliebter Weg, um Layout-Tests wie diese ist verschachtelte Klassen mit einem gegebenen verwenden/Wenn/Dann Vokabular eingeben, wie durch typische BDD Praktiken vorgeschlagen, z.B.

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

Auf diese Weise können Sie auch Tests Nest andere, die auch die passen in GivenChargeIsGreaterThanRestingCharge Geschichte an der gleichen Stelle.

Answer 3

Es ist ein bisschen lang, will Maintainer die Funktion zum Lesen eine schnelle Vorstellung davon zu bekommen, was die Funktion tut, etwas, das es lange macht schneller die Funktion selbst zu lesen.

Dies gilt auch für Tests. Wenn ich das Bedürfnis verspüren, ein Essay als Funktion Titel zu schreiben, Streifen I out ‚Wenn‘ ist ‚‘ und wiederholte Worte ... verlassen:

ChargeGreaterThanRestingButLessThanRestApproachStep_OnUpdate_ChargeSetToResting

Nicht viel weniger beschreibend, viel leichter lesbar. ..

als Windows Phone 7 Anzeigen sagen: ‚Mehr Glance and Go‘

Answer 4

die Unterstrichen geben Hinweise darauf, was denken Sie aus dem Methodennamen verschoben werden soll.

• Verschieben Sie den Klassennamen unter Test.
• Verschieben Sie, was das Testergebnis der assert-Anweisung sein soll (Kommentar falls erforderlich). Warum? Wenn sich die Aussage im Test ändert, sollte sich der Name des Tests ändern?

Dann könnten Sie haben:

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

Answer 5

Als beiseite, ein Weg (sicherlich nicht der einzige Weg) von Tests zu benennen ist Ihre Testnamen als Behauptung zu schreiben.

Ein einfaches (naives) Beispiel:

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

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

Auf der Haupt Frage denke ich lange Testfunktionsnamen sind in Ordnung, solange sie