Posts Tagged ‘altnetuk’

TypeMock – Erste Schritte

Sunday, February 17th, 2008

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 });
 
Bei TypeMock ist der Parameter der Methode ExpectAndReturn vom Typ object so dass die Typprüfung erst zur Laufzeit erfolgen kann. Rhino.Mocks Fluent Interface verwendet Generic Methods so dass der Parameter der Return Methode aus dem Typ des Property inferiert wird. Das macht sich schon bei der Eingabe sehr positiv bemerkbar, da ReSharper einen Typkonflikt sofort anzeigt, die Prüfung erfolgt statt zur Laufzeit bereits zur Compilezeit. Mit TypeMock kann man folgenden Test schreiben (und kompilieren!):
 
[TestMethod]
public void WrongReturnType() {
  Customer customer = new Customer();

  using (RecordExpectations mock = RecorderManager.StartRecording()) {
    mock.ExpectAndReturn(customer.Orders, 42);
  }
}
 
Natürlich gibt es beim Ausführen des Tests eine Exception da der Rückgabewert von Customer.Orders vom Typ IList<Order> ist und nicht int.
 
Test method WrongReturnType threw exception:  TypeMock.TypeMockException:
*** Method get_Orders in type Model.Customer cannot return System.Int32.
 
Dies hat einen erheblich größeren Einfluss auf ein flüssiges Arbeiten als man zunächst vermuten würde: wenn man im Rahmen eines Refactorings den Typ eines Properties ändert lässt der Compiler die zugehörigen Tests durchgehen da sie syntaktisch korrekt sind. Das Feedback kommt also erst zur Laufzeit der Tests. Beim Einsatz von Rhino.Mocks liefert ReSharper (oder etwas später der Compiler) bereits eine Meldung dass die Typen nicht mehr passen. Ging es bei TDD nicht um kurze Feedback Loops?

Method Chaining

Nun zu einem Highlight von TypeMock: geschachtelte Methodenaufrufe können in einem Rutsch durch ein Mock Objekt ersetzt werden.
 
[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);
}
 
Beim Einsatz von Rhino.Mocks hätte ich folgende Mock Objekte erstellen müssen: order, orderItem, product. Erst das letzte Objekt in der Kette hätte den gewünschten Wert “Red” geliefert:
 
[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);
  }
}
 
Damit dies mit Rhino.Mocks (bzw. anderen auf Proxys basierenden Mock Frameworks) funktioniert müssen für die Klassen Order, OrderItems und Product Interfaces definiert sein oder die zu mockenden Properties Order.OrderItems, OrderItem.Product, Product.Color müssen virtual sein. Hier punktet TypeMock ganz eindeutig!! Ob ich das Design konkret so wählen würde wie im Beispiel oben sei dahin gestellt (siehe zum Beispiel Law of Demeter). Wichtig ist, mit TypeMock habe ich die Freiheit dies so zu entscheiden.

Fazit

TypeMock bietet neue Freiheiten beim Testen. Es läßt Softwaredesigns zu bei denen die Entkopplung nicht auf die Spitze getrieben ist, und die trotzdem testbar sind. Mit TypeMock ist eine größere Klasse von Softwaredesigns testbar als mit Rhino.Mocks. Für mich ist das eindeutig ein Vorteil, denn nun kann ich im Einzelfall entscheiden wie weit ich die Entkopplung treiben will. Fragwürdige Designs sollten durch Code Reviews und Pair Programming aufgedeckt werden, nicht durch technische Einschränkungen der verwendeten Tools.
 
Wenn TypeMock das Fluent Interface von Rhino.Mocks hätte würde ich sofort umsteigen. So zögere ich noch…
 

ALT.NET DE Mailingliste gestartet

Friday, February 15th, 2008

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.

Technorati-Tags: ,,

ALT.NET UK

Sunday, February 3rd, 2008

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…

Technorati-Tags: ,

ALT.NET UK Konferenz in London gestartet

Saturday, February 2nd, 2008

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.

Technorati-Tags: ,