Stefan Liesers Blog

Nur noch wenige Tage bis zum ersten .NET Open Space in Leipzig am kommenden Wochenende. Bevor es los geht möchte ich mich an dieser Stelle bei Torsten und Alex bedanken. Jungs ihr habt einen super Job gemacht! Dafür vielen vielen Dank!!!

Jean-Paul S. Boodhoo ist am 29.09.2008 zu Gast in Bonn bei einer gemeinsamen Veranstaltungen der .NET Usergroups Bonn-to-Code und DNUG Köln. Es wird um das Thema Behavior Driven Development (BDD) gehen.

JP bietet 5-tägige Seminare mit dem Titel Nothin But .Net an. Die Teilnehmer dieser Seminar werden pro Tag 8 bis 14 (!) Stunden mit den aktuellsten Themen der .NET Entwicklung konfrontiert (zum Inhalt siehe z.B. hier). Wer einen Eindruck kriegen möchte was bei diesen Seminaren abgeht sollte sich den Termin 29.09.2008 nicht entgehen lassen!

P.S. Mr. Boodhoo speaks english

Wow! Schon 40 Teilnehmer haben sich angemeldet. Wir haben nur 70 Plätze zur Verfügung, also husch husch…

Vorher findet noch in London die ALT.NET UK Conference statt. Die ist allerdings schon lange ausgebucht.

Gestern Abend haben Björn, Sergey, Sebastian und ich uns zum ersten Kölner ALT.NET Bier (nein, nicht Altbier, das gibt’s in einer anderen Stadt) getroffen. Die Diskussion war prima und wir haben beschlossen dass wir uns nicht das letzte mal getroffen haben

Wer beim nächsten mal dabei sein möchte meldet sich am besten bei der deutschsprachigen ALT.NET Mailingliste an, dort geben wir den Termin bekannt. Eine weitere Möglichkeit zur Diskussion bietet die deutschsprachige ALT.NET Open Space “Konferenz” am 18./19. Oktober in Leipzig.

Und am Dienstag sehen wir uns schon wieder bei der .NET User Group Köln zum Thema WPF und Silverlight.

Am 18./19. Oktober findet in Leipzig die erste deutschsprachige ALT.NET Open Space “Konferenz” statt.

Details findet ihr hier: http://netopenspace.de

Durch das Open Space Format hat die Veranstaltung einen etwas anderen Charakter als eine klassische Konferenz: die Teilnehmer bestimmen die Inhalte selbst. Das Open Space Format wurde auch bei den ALT.NET Konferenzen in Austin, Seattle, London, etc. verwendet und hat dort hervorragend funktioniert.

Die Anmeldung erfolgt folgendermaßen:

• Zugang zum Wiki anmelden:
  http://netopenspace.de/Register.aspx
• Eure Daten eintragen:
  http://netopenspace.de/Teilnehmer.ashx
• Zur Mailingliste anmelden:
  http://groups.google.de/group/netopenspace/

Das ADO.NET Entity Framework steht immer wieder in der Kritik, wichtige Aspekte eines Object Relational Mapper (ORM) nicht umzusetzen. Neben technischen Details wie z.B. mangelhaftes Lazy Loading geht es dabei vor allem um die zu datenlastige Sichtweise des Frameworks.

Nun hat sich eine Gruppe von Entwicklern zusammen gefunden und einen offenen Brief an Microsoft geschrieben.

Hier http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/ kann der offene “Vote for No Confidence” Brief eingesehen und unterzeichnet werden.

Kurzfristig wird dadurch wohl keine Änderung am Entity Framework erreicht da “der Markt” von Microsoft eine Auslieferung erwartet. Da es aber seit Jahren Alternativen gibt ist derzeit niemand gezwungen das Entity Framework als “early adopter” einzusetzen. Vielleicht führt das bei Microsoft zu einem Umdenken.

Persönlich kann ich nur sagen dass wir mit NHibernate allerbeste Erfahrungen gemacht haben. Daran muss sich das Entity Framework messen.

Unter http://altdotnet.de/ findet sich gerade die deutschsprachige ALT.NET Bewegung zusammen. Wird’s dieses Jahr die erste Konferenz geben?

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…