Einstieg zur Workflow Foundation 4 : Unit Testing

by Gregor Biswanger 3. Dezember 2010 09:02

Ein interessanter Aspekt ist das in der Workflow Foundation 4  das automatisierte Testen von Workflows möglich ist. Das besondere daran: es lässt sich somit auch mit TDD (Test-Driven Developement) entwickeln.

Dieser Blog-Eintrag demonstriert nur das einfache Unit Testing. Wie TDD mit der WF4 umgesetzt wird, folgt mit einem eigenen Blog-Post.

Für das folgende Beispiel wird der Workflow Rechner aus dem Blog-Post “Activity selbst schreiben” verwendet.

Testen des Rechner Workflows

Dem Workflow Rechner Projekt wird eine neue Klasse mit den Namen WorkflowRechnerTest hinzugefügt. Als Unit-Test Framework wird das Open-Source Projekt NUnit verwendet. Dazu muss die Assembly NUnit.Framework.dll referenziert werden. Anschließend wird der Testklasse ein TestFixture-Attribute deklariert. Als erstes soll eine gültige Eingabe überprüft werden. Dazu wird die erste Test-Methode mit Valide_Eingabe geschrieben. Diese benötigt auch ein Test-Attribute. Durch die Attribute kann der Test-Runner die Testklassen und Methoden mittels Reflection erkennen. Dieser Artikel wird allerdings nicht weiter mit der Verwendung von Unit-Tests unter .NET eingehen.

Beim schreiben von Tests sollte sich an die AAA-Syntax gehalten werden.

 

   1:  using NUnit.Framework;
   2:   
   3:  namespace WorkflowRechner
   4:  {
   5:      [TestFixture]
   6:      public class WorkflowRechnerTest
   7:      {
   8:          [Test]
   9:          public void Valide_Eingabe()
  10:          {
  11:              // Arrange
  12:   
  13:              // Act
  14:   
  15:              // Assert
  16:          }
  17:      }
  18:  }

Listing 1  - Erste Teststruktur


Zu beginn muss das Arrange (Vorbereiten) der Instanzen folgen. Dazu wird vorerst nur eine Instanz der Workflow benötigt. Diesem wird ein Parameterwert typsicher via Property zugewiesen (Weitere Infos dazu unter “Parameter übergeben”). Das simuliert die Eingabe des Anwenders. In diesem Beispiel wäre es: “5 + 5”.

 

   1:  [Test]
   2:  public void Valide_Eingabe()
   3:  {
   4:      // Arrange
   5:      Rechner rechner = new Rechner
   6:                            {
   7:                                ArgExpression = "5 + 5"
   8:                            };
   9:              
  10:      // Act
  11:              
  12:      // Assert
  13:              
  14:  }

Listing 2 – Zuerst eine Instanz vom Workflow.

Als nächsten kommt der Act (Aktion) wo der Workflow vom WorkflowInvoker (Workflow Hoster) ausgeführt wird. Dieser gibt immer ein Dictionary zurück.

 

   1:  [Test]
   2:  public void Valide_Eingabe()
   3:  {
   4:      // Arrange
   5:      Rechner rechner = new Rechner
   6:                            {
   7:                                ArgExpression = "5 + 5"
   8:                             };
   9:              
  10:      // Act
  11:      IDictionary<string, object> results = WorkflowInvoker.Invoke(rechner);
  12:   
  13:      // Assert
  14:      
  15:  }
Listing 3 – Der Workflow wird ausgeführt.

Zum Schluss wird nur noch der Assert (Erwartung) festgelegt. Dazu bietet das NUnit Framework wie alle gängigen Test Frameworks eine statische Klasse Assert. Unter Assert wird mittels AreEqual-Methode das zu erwartende Ergebnis festgelegt worauf getestet werden soll. Das Ergebnis befindet sich im results-Objekt. Auf die Argumente (Parameter) kann normal mittels Key zugegriffen werden.

 

   1:  [Test]
   2:  public void Valide_Eingabe()
   3:  {
   4:      // Arrange
   5:      Rechner rechner = new Rechner
   6:                            {
   7:                                ArgExpression = "5 + 5"
   8:                             };
   9:              
  10:      // Act
  11:      IDictionary<string, object> results = WorkflowInvoker.Invoke(rechner);
  12:   
  13:      // Assert
  14:      Assert.AreEqual(10, results["Result"]);
  15:  }

Listing 4 – Das Ergebnis wird getestet.

Wenn der Test anschließend im Test-Runner ausgeführt wird. Wird die erwünschte Funktionalität durch grün bestätigt.

image

Abb. 1 – Ergebnis vom Unit-Test im ReSharper Test-Runner.

Fazit

Dieser Blog-Post soll nur demonstrieren wie einfach ein Workflow automatisiert getestet wird. Der Test eines Workflows ist bereits ein großer Integrationstest. Es wäre auch möglich nur die einzelnen Activites zu testen, bis hin zu den darin enthaltenen Komponenten.



Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
kick it on dotnet-kicks.de

Kommentare

Powered by BlogEngine.NET 1.4.5.0
Theme by Extensive SEO

Über den Autor

Gregor Biswanger

Microsoft MVP für Client App Dev
XING

Gregor Biswanger (Microsoft MVP für Client App Dev) ist freier Consultant, Trainer, Autor und Speaker.


Seine Schwerpunkte liegen im Bereich der .NET-Architektur, agilen Prozessen und XAML. Er veröffentlichte vor kurzem seine DVD´s mit Video-Trainings zum Thema „Meine erste Windows 8 App“, „Windows Store Apps mit XAML und C#“ und „WPF 4.5 und Silverlight 5“ bei Addison-Wesley von video2brain.


Biswanger ist auch im Auftrag von Intel GmbH als Technologieberater für die Intel Developer Zone aktiv und ist Leader bei der Ingolstädter .NET Developers Group (INdotNET). 

 

Video über mich:
http://www.youtube.com/watch?v=mx_6SiiLxjk


Basta! 2011 Speaker

CLIPer

MCTS
Windows SharePoint Services 3.0 – Application Development (MCTS)