by Oliver
Fri, March 25 2011 15:50
In my recent post Testing: trying to get it right I mentioned that a lot of our tests are of the dirty hybrid kind, somewhere between real Unit tests and real Integration tests. Focusing on the Unit test part, we’re looking into using a mocking framework right now to change the way we write tests – most of all to decouple the different components that we use in the application under test.
Wanting to use the fresh and hype NuGet package manager to install the mocking frameworks, I chose among the ones that were both available there and also looked promising:
Really, it could not have been easier to get all these libraries into the project than using NuGet!
Sample code
So I went ahead and wrote a short and simple test just to get a feel of the syntax they offer. At first I wanted to mock a simple Repository using its interface. Here is what I ended up with:
Telerik JustMock: using syntax from their quick start manual 1: public void MockRepositoryInterfaceTest()
2: {
3: // Arrange
4: var repo = Mock.Create<ITodoRepository>();
5: Mock.Arrange(() => repo.Todos)
6: .Returns(new List<Todo> {new Todo {Description = "my todo"}}.AsQueryable);
7:
8: // Act + Assert
9: repo.Todos.ToList().Count.Should().Be.EqualTo(1);
10: }
Moq: just visit the project homepage
1: public void MockRepositoryInterfaceTest()
2: {
3: // Arrange
4: var repo = new Mock<ITodoRepository>();
5: repo.SetupGet(rep => rep.Todos)
6: .Returns(() => new List<Todo> {new Todo {Description = "my todo"}}.AsQueryable());
7:
8: // Act + Assert
9: repo.Object.Todos.ToList().Count.Should().Be.EqualTo(1);
10: }
FakeItEasy: just visit the project homepage
1: public void MockRepositoryInterfaceTest()
2: {
3: // Arrange
4: var repo = A.Fake<ITodoRepository>();
5: A.CallTo(() => repo.Todos)
6: .Returns(new List<Todo> {new Todo {Description = "my todo"}}.AsQueryable());
7:
8: // Act + Assert
9: repo.Todos.ToList().Count.Should().Be.EqualTo(1);
10: }
In the first test-ride FakeItEasy and JustMock look pretty much identical, whereas the syntax Moq offers is a bit awkward with the SetupGet() method name and the need to call repo.Object to get the instance. I hope to examinate further differences in use as the project moves on.
Mocking concrete classes
Since we’re working with a large application that still has a lot of services and classes not implementing any interface I also wanted to make sure we’ll be able to mock concrete types. Well, this didn’t go so well:
JustMock and FakeItEasy simply returned an instance of the concrete class I gave them, Moq complains that it can’t override the Todos member. So I added the virtual modifier to it and the test is now green. Still, I got the impression that I was trying to do something that I shouldn’t. The following blog post motivates further not to mock concrete classes: Test Smell: Mocking concrete classes. So I guess introducing interfaces as a kind of contract between classes is the way to go, but in the meantime and where we can’t avoid mocking concrete types we’ll be left using Moq.
That’s it for now, happy coding!
Oliver
by Oliver
Fri, March 04 2011 15:18
We definitely have long paths on our client’s platform www.camping.info, for example for a concrete rating on the detail page of a campsite with a long name in a state with a long name - http://www.camping.info/deutschland/schleswig-holstein-und-hamburg/campingplatz-ferien-und-campinganlage-schuldt-19573/bewertung/r23989 - but the path (everything after the .info including the ‘/’) is still only 112 characters long which is still a long way from the 260 character barrier that’s the default in ASP.NET (see the MSDN).
The problem
Well, the same page in Greek for example has the following URL: http://el.camping.info/γερμανία/σλέσβιχ-χολστάιν-αμβούργο/campingplatz-ferien-und-campinganlage-schuldt-19573/αξιολόγηση/r23989, at least that is what we see in the browser bar. Essentially, this URL will be encoded when requesting the page from the server so it becomes a gigantic http://el.camping.info/%CE%B3%CE%B5%CF%81%CE%BC%CE%B1%CE%BD%CE%AF%CE%B1/%CF%83%CE%BB%CE%AD%CF%83%CE%B2%CE%B9%CF%87-%CF%87%CE%BF%CE%BB%CF%83%CF%84%CE%AC%CE%B9%CE%BD-%CE%B1%CE%BC%CE%B2%CE%BF%CF%8D%CF%81%CE%B3%CE%BF/campingplatz-ferien-und-campinganlage-schuldt-19573/%CE%B1%CE%BE%CE%B9%CE%BF%CE%BB%CF%8C%CE%B3%CE%B7%CF%83%CE%B7/r23989! Now the path of the URL is a whopping 310 characters long! That’s quite a bit over the limit - but even for shorter URLs the cyrillic or greek equivalents surpass the limit not as rarely as one would think once they are URL encoded.
The exception you get when exceeding the default of 260 chars is:
System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less
than 260 characters, and the directory name must be less than 248 characters.
And this is what the error looks like in Elmah:
The solution
You don’t have to search long to find a solution to this problem on the web: http://forums.asp.net/t/1553460.aspx/2/10. Just make sure the httpRuntime node contains the properties maxUrlLength AND relaxedUrlToFileSystemMapping like so:
<httpRuntime maxUrlLength="500" relaxedUrlToFileSystemMapping="true" />
You might wonder what the relaxedUrlToFileSystemMapping property really does: you can read more on MSDN. In short, if set to true “the URL does not have to comply with Windows path rules” (MSDN).
Happy coding,
Oliver
by robert
Sun, June 13 2010 14:15
Gute Software Architektur ist schwer und das Feld noch sehr jung. Obwohl sich DI und IoC auch im Mainstream durchzusetzen scheinen und die PoEAA Stück für Stück in den Wortschatz von Entwicklern einkehren, ist noch Platz nach oben.
Einen inkrementellen Fortschritt könnten EBCs darstellen. In diese Richtung zu denken, kann schnell und praktisch unseren Entwickleralltag bereichern. Wer lernen und sich über die Konzepte von EBC austauschen möchte, tut dies am besten auf der neuen Mailingliste: Event based Components.
by robert
Thu, June 10 2010 10:02
Ist zu viel Konstruktor-Injizierung ein Anti-Pattern? In einem Blog-Post konstruiert Jeff Palermo ein Beispiel, in dem eine injizierte Komponente eine wirklich langsame Initialisierung hat. Da die Komponente nur von einer Methode der Klasse benötigt wird, leitet er ab, dass statt der Konstruktor-Injizierung von Komponenten eine Lazy-Factory die bessere Alternative ist.
Die Kommentare lehnen diesen Schluss fast fast einhellig ab, denn:
1) Eine Verzögerung der Initialiszierung ist auch über den Container und mit .NET 4 auch über System.Lazy<> zu erreichen.
2) Gegen eine Schnittstelle zu programmieren bedeutet gerade, dass man Implementierungsdetails nicht in der Hand hat.
3) Langwierige Initialisierung in der Komponente bedeutet, dass die Komponente minderer Qualität ist, hier muss dann nachgebessert werden. Es sollten keine aufwändigen Operationen in der Konstruktor-Implementierung durchgeführt werden.
4) Ein Abstrakte Fabrik erzeugt ein Abhängigkeit gegenüber dieser, was die Menge der Abhängigkeiten steigert und die Vorteile des IoC reduziert. Jedes „new“ ist bad „news“.
5) Um häufige Initialiserung zu umgehen, könnten Services als Singelton konfiguriert werden, wobei globale Konfiguration ein Problem sein kann, weil sie schwer zu Debuggen und auf Anwendungsebene auch schwer nachzuvollziehen sein kann.
Danke an Jeff Palermo für seinen sehr lesenwerten Post!
Links:
by Oliver
Fri, November 13 2009 22:33
Hier (http://blogs.msdn.com/kcwalina/archive/2004/05/18/134208.aspx#5943757) habe ich eine Methode gefunden, wie man einfach und ohne Mathekenntnisse (für einige von uns ;-)) Flag-Enums definiert:
enum Color
{
None = 0,
Blue = 1 << 0,
Red = 1 << 1,
Yellow = 1 << 2,
Purple = Blue | Red,
Orange = Red | Yellow,
}
Oliver
by robert
Sun, November 01 2009 16:36
Das Digram soll die tatsächlich Architektur für den _ersten_ Schritt des Einbaus zeigen.
Die physischen Abhängigkeiten sehen nochmal anders aus, da die GUI direkt mit Typen aus der Applikation arbeitet.
Die architektonische "Schichtung" ergibt sich aus der Notwendigkeit "zirkuläre" Referenzen zu verhindern. Aus diesem Grund sind Container und Service-Locater auch physisch getrennt.
Ein volle Entkopplung macht im tatsächlichen Anwendungsfall aus jetziger Perspektive auch keinen Sinn und ließe sich auch leicht nachträglich einziehen.
83fa28a2-5c2f-40a3-a972-403b2bd7419e|0|.0
Tags:
Architecture
by robert
Sat, October 31 2009 22:24
Mit Legacy Projekt ist ein Projekt gemeint, das keine automatisierten Tests besitzt und nicht trivial ist. Es scheint unmöglich DI in einem Entwicklungsschritt einzuführen. Es scheint nicht sinnvoll im ersten Schritt die Anwendungsschicht von der Abhängigkeit auf das Container Framework zu befreien.
Meine aktuelle Strategie:
- In kleinen Schritten vorgehen
- Viele kleine Service-Locator einsetzten
- Die Service-Locator arbeiten alle mit der gleichen Singelton Instanz des Containers
- Im Muster denken: "Refaktorisierung in Richtung" wobei die endgültige Refaktorisierung auch Wochen/Monate auf sich warten kann.
c083acf8-3db1-43d3-aaae-f89edbc9a90a|0|.0
Tags:
Architecture
.NET (40)