Stefan Liesers Blog

Aufgrund der Diskussionen während der ALT.NET UK Konferenz habe ich beschlossen mir TypeMock mal genauer anzuschauen. Vor allem der Support für Method Chaining interessiert mich. Aber immer der Reihe nach…

TypeMock ist ein kommerzielles Mock Framework. Es ist in drei Varianten verfügbar: Community, Professional und Enterprise (siehe Gegenüberstellung der Features). TypeMock verwendet das Profiler API um Aufrufe von Methoden abzufangen. Bisher arbeite ich mit Rhino.Mocks das für diesen Zweck Castle DynamicProxy verwendet. Mock Frameworks die auf Proxys basieren können lediglich Interfaces und virtuelle Methoden mocken. Das Ersetzen einer konkreten Klasse die kein Interface implementiert oder das Ersetzen nicht-virtueller oder statischer Methoden (inkl. Extension Methods) oder LINQ Querys ist mit solchen Frameworks technisch bedingt nicht möglich.

Bislang ging ich davon aus dass dies in der Praxis keine wirkliche Einschränkung für mich ist da es dazu führt, Klassen lose zu koppeln damit sie getestet werden können. Während der ALT.NET UK Konferenz wurde von Roy Osherove die Befürchtung geäußert dass man als Software Entwickler Designentscheidungen zur losen Kopplung von Komponenten weiter treibt als eigentlich sinnvoll, “nur” damit die Klassen getestet werden können. TypeMock verspricht diese technische Einschränkung aufzuheben.

In den Beispielen verwende ich ein weiteres Framework zum ersten mal: MSTest. Bislang habe ich NUnit eingesetzt (und werde das wohl auch weiterhin tun). Da MSTest in Visual Studio integriert ist und Code Coverage Analyse mitbringt bin ich sehr gespannt wie es sich für einen NUnit Nutzer “anfühlt”.

Vorbereitungen:

• TypeMock Download von hier.
• Installation
• Tools | Add-in Manager… | TypeMock Isolator aktivieren

Erster Test:

using Microsoft.VisualStudio.TestTools.UnitTesting;
using TypeMock;

namespace Model
{
  [TestClass]
  public class CustomerTests
  {
    [TestMethod]
    public void Orders_can_be_mocked() {
      Order order = RecorderManager.CreateMockedObject<Order>();
      Customer customer = new Customer();

      using(RecordExpectations mock = RecorderManager.StartRecording()) {
        mock.ExpectAndReturn(customer.Orders, new Order[] { order });
      }

      Assert.AreSame(order, customer.Orders[0]);
    }
  }
}

Wenn TypeMock nicht aktiviert sein sollte erhält man folgende Fehlermeldung. Vorbildlich dass in der Meldung gleich beschrieben ist wie man das Problem abstellt!

Test method Orders_can_be_mocked threw exception:  TypeMock.TypeMockException:
*** Typemock Isolator is not currently enabled.
To enable do one of the following:

* To run Typemock Isolator as part of an automated process you can:
   - run tests via TMockRunner.exe command line tool
   - use 'TypeMockStart' tasks for MSBuild or NAnt

* To work with Typemock Isolator inside Visual Studio.NET:
        set Tools->Enable Typemock Isolator from within Visual Studio

For more information consult the documentation (see 'Running' topic).

Kein Fluent Interface

Da ich die Syntax von Rhino.Mocks gewohnt bin vermisse ich das Fluent Interface mit seiner compiletime Typsicherheit (siehe dazu hier):

// TypeMock
mock.ExpectAndReturn(customer.Orders, new Order[] { order });

// Rhino.Mocks
Expect.Call(customer.Orders).Return(new Order[] { order });

[TestMethod]
public void WrongReturnType() {
  Customer customer = new Customer();

  using (RecordExpectations mock = RecorderManager.StartRecording()) {
    mock.ExpectAndReturn(customer.Orders, 42);
  }
}

Test method WrongReturnType threw exception:  TypeMock.TypeMockException:
*** Method get_Orders in type Model.Customer cannot return System.Int32.

Method Chaining

[TestMethod]
public void MethodChaining() {
  Customer customer = new Customer();

  using (RecordExpectations r = RecorderManager.StartRecording()) {
    r.ExpectAndReturn(customer.Orders[0].OrderItems[0].Product.Color, "Red");
  }

  Assert.AreSame("Red", customer.Orders[0].OrderItems[0].Product.Color);
}

[TestMethod]
public void MethodChaining_Rhino() {
  MockRepository mocks = new MockRepository();
  IOrder order = mocks.DynamicMock<IOrder>();
  IOrderItem orderItem = mocks.DynamicMock<IOrderItem>();
  IProduct product = mocks.DynamicMock<IProduct>();

  Customer customer = new Customer();
  customer.Orders.Add(order);
  using (mocks.Record()) {
    Expect.Call(order.OrderItems).Return(new IOrderItem[] {orderItem});
    Expect.Call(orderItem.Product).Return(product);
    Expect.Call(product.Color).Return("Red");
  }
  using (mocks.Playback()) {
    Assert.AreSame("Red", customer.Orders[0].OrderItems[0].Product.Color);
  }
}

Fazit

Ich habe soeben hier http://groups.google.com/group/altnetde/ eine deutsche ALT.NET Mailingliste gestartet. Würde mich freuen dort den ein oder anderen ALT.NETer wiederzutreffen.

Wir hatten am Freitagabend so viele Themen gesammelt dass es für vier parallele Sessions gereicht hat. Ich beschreibe im folgenden kurz an welchen Sessions ich teilgenommen habe.

Session 1

In der ersten Session ging es um die Frage, inwieweit Testdriven Development (TDD) und die dabei eingesetzten Tools Designentscheidungen einschränken. Roy Osherove argumentiert, dass TDD dazu führen kann Dependency Injection einzusetzen um eine Klasse testen zu können (indem sie von den internen Abhängigkeiten befreit wird), obwohl dies nicht durch eine Designentscheidung begründet ist.

Ein Beispiel stellt die Verwendung eines Loggers dar, dessen statische Methode innerhalb einer Klasse verwendet wird. Soll der Logger im Unit Test durch ein Mock Objekt ersetzt werden, so ist dies mit Mock Frameworks die zur Laufzeit ein Interface implementieren oder eine Klasse ableiten nicht möglich da Interfaces keine statischen Methoden enthalten dürfen bzw. statische Methoden in Klassen nicht virtuell sein können. Lediglich TypeMock kann solche statischen Methoden ersetzen da es das Profiler API verwendet. Bietet das eingesetzte Mock Framework keine Unterstützung für statische Methoden bleibt einem nichts anderes übrig als den Logger über ein Interface zu abstrahieren und per Dependency Injection in die Klasse einzufügen.

Eine andere Stelle an der Mock Frameworks die nicht auf dem Profiler API aufsetzen scheitern ist LINQ. Wenn eine Methode LINQ verwendet und Unit Tests prüfen sollen wie sich die Methode bei den unterschiedlichen Resultaten der Query verhält bleibt einem nichts anderes übrig als die LINQ Query über ein Interface zu abstrahieren. Möglicherweise würde man dieses Design ohnehin bevorzugen, der Punkt ist jedoch dass die eingesetzten Tools diese Entscheidung erzwingen, die Möglichkeiten aus denen man wählen kann also eingeschränkt werden.

Session 2

In der zweiten Session ging es um die Frage inwieweit F# oder Ruby als Ergänzung oder Alternative zu C# verwendet werden können. Einhellige Meinung war, dass es sich in jedem Fall positiv auswirkt sich mit anderen Sprachparadigmen (funktional bzw. dynamisch) zu beschäftigen in dem Sinne, dass man seine Sichtweise erweitert.

Session 3

Nach dem Mittagessen ging es in Session 3 um NHibernate bzw. ganz allgemein um Object Relational Mapper (ORM). Es wurde z.B. diskutiert inwiefern LINQ to SQL eine Alternative zu NHibernate darstellt und ob das Microsoft Entity Framework einen vollwertigen Ersatz für NHibernate bilden wird.

In dieser Session fand ein reger Know How Austausch statt da viele der Anwesenden NHibernate regelmäßig einsetzen.

Session 4

Die letzte Session befasste sich mit Domain Specific Languages (DSL) und Fluent Interfaces. Zu Fluent Interfaces warf Roy erneut die Frage auf inwieweit diese während des Testens mit Hilfe von Mock Frameworks ersetzt werden können. Das Problem liegt darin, dass Fluent Interfaces durch ihre Punktnotation viele geschachtelte Methodenaufrufe verursachen. Mit Hilfe der "konventionellen" Mock Frameworks muss jede Ebene eines solchen Aufrufes explizit behandelt werden. Lediglich TypeMock ist bislang in der Lage einen solchen Aufruf "in einem Rutsch" zu behandeln (chained natural mock).

Desweiteren ging es um die Frage ob es sinnvoll ist eine DSL innerhalb einer anderen Sprache zu unterstützen um beispielsweise den Setupteil eines Tests in einer DSL zu beschreiben während die Tests in C# programmiert sind. Ein Grundproblem scheint, neben der Implementierung, das Design einer guten DSL zu sein.

Persönlich setze ich Fluent Interfaces im Bereich von Tests ein um den Aufbau von Testdaten aus den Business Domain Objects übersichtlicher zu gestalten. Ferner habe ich ein Fluent Interface verwendet um Regeln für die Eingabevalidierung im Presenter zu formulieren. In diesen Bereichen werden ich Fluent Interfaces in Zukunft sicherlich stärker einsetzen.

Fazit

Es hat sich in jedem Fall gelohnt nach London zu fahren!! (obschon die Anreise bedingt durch einen kurzfristigen Streik des belgischen Eisenbahnpersonals 3 Stunden länger dauerte als geplant) Ich habe viele interessante Leute kennen gelernt und sehr fruchtbare Diskussionen geführt. Es bleibt erneut die Frage wo die deutsche ALT.NET Bewegung steht…

Gestern Abend haben sich die Teilnehmer der ALT.NET Konferenz in London getroffen um Vorschläge zum Inhalt der Konferenz zu sammeln. Die Konferenz wird Open Space organisiert. Wer, wie ich, zum ersten mal eine Open Space Konferenz erlebt fragt sich wie das gehen soll. Wir standen also alle zusammen, stellten uns kurz vor, und dann wurden Themen gesammelt. Die Dynamik dieser Runde war spitze! Jeder der zu einem Thema etwas anzubieten hat erklärt in ein paar Sätzen um was es geht, schreibt ein paar Stichworte auf einen Klebezettel und heftet diesen an eine vorbereitete Wand. An Themen wurde vieles genannt was in der .NET Community diskutiert wird. Die Wand ist jedenfalls voller Klebezettel.

Anschließend ging es in eine Bar zum Smalltalk. Dort zeigte sich dann dass ich in der Schule im Englischunterricht offensichtlich anderes zu tun hatte Zuhören und Verstehen ist kein Problem, aber die Suche nach den richtigen Wörtern dauert… Es war jedenfalls ein gelungener Abend mit interessanten Leuten und spannenden Gesprächen.

Heute morgen wird es erst mal darum gehen Ordnung in die Themenvorschläge zu bringen, sie zusammen zu fassen. Dann kann sich jeder Teilnehmer entscheiden an welchen Themen er arbeiten möchte und los geht’s.