UnitTests, ripulire la tua dichiarazione di attualità rende il tuo test più o meno chiaro?

//Act, we need the resulting bar when the int parameter is 10:
var bar = fooObject.PerformFoo(intParameter: 10);

Quando uno sviluppatore incontra questo test unitario, mi ci vorranno alcuni secondi per andare oltre quel metodo "proxy" e capire quale comportamento della classe sottoposta a test viene effettivamente testato, poiché non vi è alcuna menzione diretta del metodo originale Quindi non direi che è più leggibile di un test che usa la cosa reale. Questo ulteriore livello è anche soggetto a errori. A mio parere, il metodo utilizzato nella sezione Act dovrebbe sempre essere lo stesso metodo che vogliamo testare.

Nel tuo esempio originale, usi variabili anonime per rendere i parametri irrilevanti più trasparenti, penso che sia il modo ragionevole per semplificare i test, come

fooObject.Foo("", 0, (bar)=>{}, (bar)=>{});

Se lo facessi, darei un'occhiata all'impostazione di base che agisce chiamando Foo() . Una classe base conterrà l'Arrange con valori predefiniti, l'Act sarà nella base e l'assert dovrebbe essere assunto nelle classi di test figlio.

[TestClass] //you don't need this here but the 
            //compiler warns otherwise with mstest :(
public void Base_Fooey_fixture
{
   protected String StringParameter { get; set; }
   protected int IntParameter { get; set; }
   // ...
   [ClassInitialize]
   public void Arrange()
   {
     StringParameter = "Default Value";
     //...
   }
   [TestInitialize]
   public void Act()
   {
    Foo(StringParameter, IntParameter, SuccessCallback, ErrorCallback);  
   }
}
[TestClass]
public class RealTest : Base_Fooey_fixture
{
   [ClassInitialize]
   public class MyArrange()
   {
     StringParameter = "My real string value";
   }

   [TestMethod]
   public void Im_gonna_assert_for_this_setup()
   {
      //...
   }
}

Non sono sicuro che l'utilizzo dei callback per l'asserzione di eccezioni sia meglio dell'attributo [ExpectedException].

Per un codice di prova, non è diverso da qualsiasi altro codice in cui vuoi che sia chiaro.

Nei miei test, di solito applico i principi di programmazione al codice di test che trovo produttivo senza esitazione.

La composizione è un potente strumento per formare un linguaggio ubiquo specifico per il modello di dominio, ma a mio gusto, il metodo PerformBar è troppo generico. Di solito finisco con metodi di composizione più specializzati.

public class RandomQueueGeneratesSequence
{
 private IEnumerable<T> ActualResult<T>(IEnumerable<T> source, int seed)
 {
  // Setup
  var q = new RandomQueue(new Random(seed));

  // Act
  foreach(var i in source)
    q.Add(i);
  var l = new List<T>();
  while( q.HasItems )
  {
   l.Add(q.GetItem());
  }
  return l;
 }
 [Test, Combinatorial] 
 public void ContainingAllSourceItems([Values(0,1,12345)] int seed)
 {
  CollectionAssert.AreEqualent(new[]{1,2,3}, ActualResult(new[]{1,2,3},seed));
 }
 [Test, Combinatorial]
 public void WithSingleItem([Values(0,1)] expectedValue, [Values(0,1,12345)] int seed)
 {
  Assert.AreEqual(expectedValue, ActualResult(new[]{expectedValue}, seed).Single());
 }
 [Test]
 public void InOrderBySeed1()
 {
  CollectionAssert.AreEqual(new[]{1,2}, ActualResult(new[]{1,2}, 123));
 }
 [Test]
 public void InOrderBySeed2()
 {
  CollectionAssert.AreEqual(new[]{2,1}, ActualResult(new[]{1,2}, 456));
 }
}

In questo esempio, non è ragionevole comporre i metodi di asserzione, perché vengono utilizzati metodi diversi (Assert.AreEqual, CollectionAssert.AreEqual, CollectionAssert.AreEqualent).

Ma se ci sono più di due test segui un pattern, trovato in InOrderBySeed, sposta un assert a un metodo di composizione e assegnagli un Assert :

 protected void AssertInOrder<T>(IEnumerable<T> expected, IEnumerable<T> source, int seed)
 {
  CollectionAssert.AreEqual(expected, ActualResult(source, seed));
 }

 public void InOrderBySeed1()
 {
  AssertInOrder(new[]{1,2}, new {1,2}, 123);
 }
 [Test]
 public void InOrderBySeed2()
 {
  AssertInOrder(new[]{2,1}, new[]{1,2}, 456);
 }
 [Test]
 public void InOrderBySeed3()
 {
  AssertInOrder(new[]{3,1,2}, new[]{1,2,3}, 789);
 }

Generalmente, quando il codice del test diventa abbastanza chiaro, ti ritroverai a non aver più bisogno di commenti. Soprattutto quando l'intento è chiaro da un nome di metodo. In questo esempio - il prefisso Assert annulla il commento // Assert .