2010-05-06 3 views
6

Ces trois tests sont identiques, sauf qu'ils utilisent une fonction statique différente pour créer une instance StartInfo. J'ai ce modèle à venir tout au long de mon code de test, et j'aimerais pour être en mesure de simplifier cela en utilisant [TestCase], ou de toute autre manière qui réduit le code standard. Au meilleur de ma connaissance, je ne suis pas autorisé à utiliser un délégué comme argument [TestCase], et j'espère que les gens ici auront des idées créatives sur la façon de rendre le code ci-dessous plus concis.Comment simplifier ces tests NUNit?

[Test] 
    public void ResponseHeadersWorkinPlatform1() 
    { 
     DoResponseHeadersWorkTest(Platform1StartInfo.CreateOneRunning); 
    } 
    [Test] 
    public void ResponseHeadersWorkinPlatform2() 
    { 
     DoResponseHeadersWorkTest(Platform2StartInfo.CreateOneRunning); 
    } 
    [Test] 
    public void ResponseHeadersWorkinPlatform3() 
    { 
     DoResponseHeadersWorkTest(Platform3StartInfo.CreateOneRunning); 
    } 

    void DoResponseHeadersWorkTest(Func<ScriptResource,StartInfo> startInfoCreator) 
    { 
     ScriptResource sr = ScriptResource.Default; 
     var process = startInfoCreator(sr).Start(); 
     //assert some things here 
    } 

Répondre

8

Premièrement, je ne pense pas que l'original soit trop mauvais. C'est seulement désordonné si vos assertions sont différentes du cas de test au cas de test.

De toute façon, vous pouvez utiliser un cas de test, mais cela ne peut pas être effectué via un attribut [TestCase] ​​standard en raison de l'utilisation de types plus complexes. Au lieu de cela, vous devez utiliser un IEnumerable public <> en tant que fournisseur de données, puis marquer votre méthode de test avec un attribut [TestCaseSource].

Essayez quelque chose comme:

public IEnumerable<Func<ScriptResource, StartInfo>> TestCases 
    { 
     get 
     { 
      yield return Platform1StartInfo.CreateOneRunning; 
      yield return Platform2StartInfo.CreateOneRunning; 
      yield return Platform3StartInfo.CreateOneRunning; 
     } 
    } 

    [TestCaseSource("TestCases")] 
    public void MyDataDrivenTest(Func<ScriptResource, StartInfo> startInfoCreator) 
    { 
     ScriptResource sr = ScriptResource.Default; 
     var process = startInfoCreator(sr); 

     // do asserts 
    } 
} 

Ceci est une version plus concise du modèle standard de rendement des instances TestCaseData contenant les paramètres. Si vous générez des instances de TestCaseData, vous pouvez ajouter plus d'informations et de comportements à chaque test (comme les exceptions attendues, les descriptions, etc.), mais il est légèrement plus détaillé.

Une partie de la raison pour laquelle j'aime vraiment ce genre de choses est que vous pouvez faire une méthode pour votre «acte» et une méthode pour votre «affirmer», puis les mélanger et les faire correspondre indépendamment. Par exemple. mon ami faisait quelque chose hier où il a utilisé deux actions pour dire ("quand la méthode Blah est appelée, cette méthode sur le ViewModel doit être déclenchée"). Très laconique et efficace!

+1

m'a appris un nouveau concept !!! plus +1 – Prashant

+0

+1 gentil. Voici un lien [NUnit doc avec des exemples] amélioré (http://nunit.org/index.php?p=testCaseSource&r=2.10.10). –

0

Cela semble bon. Cherchez-vous à ajouter une usine peut-être? Vous pouvez également ajouter ces méthodes à une liste d'actions (dans la configuration de test) et appeler le délégué de première action, le deuxième délégué d'action et le troisième délégué d'action.

Questions connexes