Posts Tagged ‘altnetde’

ALT.NET Open Space – schon 40 Anmeldungen

Saturday, August 16th, 2008

.NET Open Space vom 18.10. bis 19.10.2008 in Leipzig

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.

Technorati-Tags: ,

ALT.NET Bier in Köln

Tuesday, August 5th, 2008

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.

Technorati-Tags: ,

Deutschsprachige ALT.NET Open Space Konferenz

Tuesday, August 5th, 2008

.NET Open Space vom 18.10. bis 19.10.2008 in Leipzig 

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:

Technorati-Tags: ,

ALT.NET DE

Monday, June 23rd, 2008

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

Technorati-Tags: ,

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: ,,