2016-05-18 19 views
0

Ich suche nach einer guten Möglichkeit, meine Komponententests in einem .NET-Projekt zu organisieren. Im Moment habe ich eine TestClass pro Anwendungsklasse mit mehreren Tests für jede Methode. Obwohl ich TestCategory verwende, um jedes TestMethod durch die Anwendungsklassenmethode zu kategorisieren, die er prüft, wird das Finden meiner Testmethoden unbeholfen.Testklassen in Teilklassen aufteilen?

Ich überlege, meine Testklassen in Teilklassen aufzuteilen - eine Teilklasse pro Anwendungsklassenmethode. Das bedeutet, dass ich mehrere TestMethod in einer dedizierten Datei pro Methode haben kann, ohne eine große Datei durchsuchen zu müssen, um sie zu finden.

Gibt es irgendwelche Nachteile bei diesem Ansatz? Gibt es bessere Möglichkeiten, große Testklassen in .NET und Visual Studio zu behandeln?

Edit: Ich verwende IoC (wir verwenden Castle.Windsor für DI außerhalb der Tests) und wir verwenden Moq für Mocking-Funktionen. Tests werden mit TestInitialize initialisiert.

+0

Sie können für jede Methode eine Testklasse erstellen. Zum Beispiel haben Sie Klasse C1 mit den Methoden M1 und M2. Erstellen Sie 2 Testklassen 'C1_M1_Test' und' C1_M2_Test'. –

+0

Sie können Ihre getesteten Klassen in mehrere kleinere Klassen aufteilen, anstatt Ihre Tests zu teilen. – Carra

+0

@Carra Nein ... eine Methode kann mehrere Tests haben. Wenn eine Klasse drei Methoden hat und jede Methode sechs Tests hat ... das sind achtzehn Tests in einer Testklasse. Das Ändern der Anwendungsklassen befasst sich nicht wirklich mit dem Problem - es geht um das Wachstum auf der falschen Seite der Gleichung. –

Antwort

0

Werfen Sie einen Blick auf meine Antwort C# ASP.NET MVC Controller unit test. Der Kern ist:

  • eine statische Klasse, die für ein bestimmtes zu testende System alle Tests wickelt.
  • eine Testklasse für jedes Testszenario Sie Laufen sind, die

Die andere nette über dieses Setup von einer Basisklasse erbt, ist, dass es Ihnen einen schönen Baum von Tests gibt, wenn Sie das resharper Gerät verwenden Testsitzung, um Ihren Test einfach finden zu können.

Wie für die erste Antwort sollten Sie nicht ein DI-Framework in Ihren Tests verwenden. Alle externen Abhängigkeiten sollten verspottet werden, so dass Sie nur das zu testende System testen.

Und für die Verwendung von Teilklassen. Siehe Are C#'s partial classes bad design?

Ich stimme mit Carra, mit partiellen Klassen nur eine lange Klasse zu teilen ist als schlechtes Design. Wenn Ihre Klasse so groß ist, muss sie vielleicht aufgeteilt werden.

+0

Hmm. Ich kann das Vererbungsmuster berücksichtigen, aber ich benutze nicht Resharper. Ich bin mir nicht sicher, ob die statische Klasse in meinem Fall notwendig ist. Wir verwenden Mocks, aber wir verwenden DI nicht in den Tests selbst (wir sind in der Anwendung). Ich nehme an, dass das eigentliche Problem, das ich zu lösen versuche, das Fehlen verschachtelter Testspezifikationen ist - ich denke, dass das Klasse-pro-Methode-Paradigma eine sehr schlechte Lösung dafür ist. –

+0

Im Wesentlichen ... Ich weiß, ich suche nach etwas, das der "Describe" -Funktion in [Mocha] ähnelt (https://mochajs.org/) - eine Möglichkeit, meine Tests logisch zu strukturieren, ohne durch die Ringe springen zu müssen um es zu tun. –

+0

Die statische Klasse dient nicht zum Nachschärfen, sondern zum logischen Gruppieren aller Testszenarien einer bestimmten Klasse. Je nach Verzweigungslogik in dieser Methode können Sie mehr als eine Klasse pro Methode verwenden. Sie können auch eine Reihe von Tests unter 1 Klasse gruppieren. Beachten Sie in meinem Beispiel, wie ich mehrere Tests in meiner ersten Instanz habe, weil sie den Verlauf der Tests nicht ändern. dann bringe ich spezifische Szenarien zu eigenen Tests heraus. – Fran

0

Ich würde Ihre Tests einfach und prägnant halten. Die Trennung Ihrer Tests könnte von Vorteil sein, aber wo initialisieren Sie Ihren Testcode? Verwenden Sie Inversion of Control, um Arbeiten auszuführen, die die anderen Tests bereits ausgeführt haben sollten? Wenn ja, dann sollten Sie sich [TestInitialize] ansehen und Ihre Abhängigkeiten organisieren.

Hier ist, was ich meine für TestInit zentralisieren

[TestClass] 
public class UnitTestWebsiteBuilderPattern 
{ 
    private IHtmlInputService _htmlInputService; 
    private IHtmlControlService _htmlControlService; 
    private IHtmlMenuControlService _htmlMenuControlService; 
    private IHtmlConditionalInputService _htmlConditionalInputService; 
    private IHtmlPanelService _htmlPanelService; 
    private IHelpIconService _helpIconService; 
    private IHtmlModalService _htmlModalService; 

    [TestInitialize] 
    public void Init() 
    { 
     _helpIconService = new HtmlHelpIconService(); 

     _htmlInputService = new HtmlInputService(_helpIconService); 
     _htmlPanelService = new HtmlPanelService(_htmlInputService); 

     _htmlModalService = new HtmlModalService(_htmlPanelService); 
     _htmlControlService = new HtmlControlService(_htmlPanelService); 

     _htmlMenuControlService = new HtmlMenuControlService(); 
     _htmlConditionalInputService = new HtmlConditionalInputService(); 

    } 
+0

Ich mache das bereits mit Moq. Das Problem mit mehreren Klassen hier ist, dass ich diesen Code überall wiederholen würde (es sei denn, ich habe von einer Basis-Testklasse geerbt, die mit der Anwendungsklasse übereinstimmt, oder so). –

+0

können Sie di verwenden, um Ihre app_start für Ihre Unit-Tests private statische Void RegisterServices (IKernel Kernel) – Programmer

+0

zu zentralisieren, da Sie Castle Windsor verwenden können Sie erwartet Ergebnisse und Ihre Erwartung ist korrekt. Wie für Teilklassen zum Testen, um Tests mehr Spaß und einfacher zu machen, Redesign. http://www.codeproject.com/Articles/5772/Advanced-Unit-Test-Part-V-Unit-Test-Patterns – Programmer