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:
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:
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).
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.
[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); } }
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.
