ADO.NET Entity Framework, Table Module & Rhino Mocks
Laurin Stoll
Ich verzweifel beinahe. Also erstmal verzweifel ich an ADO.NET Entity
Framework. Wie kann man sowas neues so schlecht umsetzen? Das soll ein
O/R Mapper sein? Um gottes willen. Naja leider kann ich bei dem
Projekt nicht wählen und kann meinen gelieben Telerik Open Access
nicht einsetzen. Wird schon gehen.
Nun habe ich aber ein zünftiges Problem beim Testen. Auch hier drängt
sich wieder die Frage auf:
Wie kann Microsoft etwas so testunfreundliches entwickeln??
Ich verwende Rhino Mocks und brauche eure Hilfe.
Gerne würde ich folgenden Aufruf testen, kriegs aber nicht gebacken:
public override bool CanLogOn(string winNTName)
{
return this.ObjectEntitiesContext.User.Where(u =>
u.Win32Username == winNTName).Count() > 0;
}
Im Moment ist da noch nicht wirklich viel Logik drin.
Jetzt würde ich gerne im UnitTest halt einfach einmal einen User
zurück geben und einmal nicht. Da kommt der Knüppel aber gerade
Knallhart. Der ObjectContext.User gibt ein ObjectQuery<User> zurück
und darauf wird eine Extension Method angewendet. Ehrmm....
Wie mach ich das mit Rhino mocks??
ABB_PPEntities contextMock =
MockRepository.GenerateMock<ABB_PPEntities>();
ObjectQuery<User> userQueryMock =
MockRepository.GenerateStub<ObjectQuery<User>>();
// ... heisse Luft...
kann mir jemand helfen? Ach herje.... :(
Viele Grüsse
Laurin
Alexander Groß
ich habe noch nicht mit EF gearbeitet und kann dir deshalb leider nicht
konkret weiterhelfen, aber einen Workaround aus der Kategorie "every problem
in computer science can be solved by another layer of abstraction" anbieten:
Verstecke alle EF-Querys hinter einem IRepository (welches sich einfach
mocken lässt).
Beispielsweise:
public override bool CanLogOn(string winNTName)
{
return repository.FindUserByName(Win32Username) != null;
}
HTH,
Alex
--
Alexander Groß
http://therightstuff.de/
Stefan Lieser
würde ich auch so machen. Zur Ergänzung: die konkreten Repositories
testest du am besten gegen eine echte Datenbank. Das geht pro Test wie
folgt:
- Datenbank leeren und Schema neu aufbauen
- Testdaten schreiben (da deine Objekte gemappt sind kanns du das
Schreiben der Testdaten mit dem EF machen)
- Test ausführen
Grüße
Stefan Lieser
Laurin Stoll
Besten Dank für eure Antworten. Ja das dacht ich mir schon, dass es zu
Aufwändig wird mit dem testen von EF und ExtensionMethods.... hm.
Dann gibts wohl oder übel ein IUserRepository welches alle Aufrufe
kapselt. Das ist Io.
Trotzdem noch zwei Fragen:
1) Kann ich extension methods mit Rhino Mocks überhaupt testen (irgend
sowas habe ich bei dir im Blog gefunden Stefan... glaube ich finds
aber nicht mehr)
2) Eine völlig andere Frage(sorry): Ich habe ein Lastenheft vom Kunden
mit ungefähr 100 punkten. Diese würde ich gerne in Acceptance tests
umformen. Wie macht ihr das? Ein Unit Test Projekt wo ihr die
Lastpunkte abbildet??
Besten Dank und viele Grüsse :)
Laurin
>
> - Zitierten Text anzeigen -
Stefan Lieser
> Dann gibts wohl oder übel ein IUserRepository welches alle Aufrufe
> kapselt. Das ist Io.
Die Kapselung der Datenzugriffe in einem Repository ist eh best
practice.
> 1) Kann ich extension methods mit Rhino Mocks überhaupt testen (irgend
> sowas habe ich bei dir im Blog gefunden Stefan... glaube ich finds
> aber nicht mehr)
Extension Methods sind syntactic sugar und werden vom Compiler in
statische Methoden übersetzt. Statische Methoden können nicht von
Rhino Mocks ersetzt werden. Dies liegt an der Form der
Implementierung: Rhino verwendet Proxy Klassen. Da statische Methoden
nicht überschrieben werden können geht das rein prinzipbedingt nicht.
> 2) Eine völlig andere Frage(sorry): Ich habe ein Lastenheft vom Kunden
> mit ungefähr 100 punkten. Diese würde ich gerne in Acceptance tests
> umformen. Wie macht ihr das? Ein Unit Test Projekt wo ihr die
> Lastpunkte abbildet??
Ein eigenständiges Projekt hört sich schonmal nicht verkehrt an. Für
die Umsetzung kannst du BDD-style Tests verwenden. Mit dem daraus
erstellten Report kannst du dann zum Kunden gehen und klären, ob alles
richtig ist. Eine Alternative sind Fit/Fitnesse Tests.
Grüße
Stefan
Laurin Stoll
> Die Kapselung der Datenzugriffe in einem Repository ist eh best
> practice.
Repository... aber du hast schon recht, werd das mal so machen.
> Extension Methods sind syntactic sugar und werden vom Compiler in
> statische Methoden übersetzt. Statische Methoden können nicht von
> Rhino Mocks ersetzt werden. Dies liegt an der Form der
> Implementierung: Rhino verwendet Proxy Klassen. Da statische Methoden
> nicht überschrieben werden können geht das rein prinzipbedingt nicht.
> Ein eigenständiges Projekt hört sich schonmal nicht verkehrt an. Für
> die Umsetzung kannst du BDD-style Tests verwenden. Mit dem daraus
> erstellten Report kannst du dann zum Kunden gehen und klären, ob alles
> richtig ist. Eine Alternative sind Fit/Fitnesse Tests.
Aber was sind FIT Tests??
Wie sieht das konkret aus? Ich habe quasi ein Excel File wo ich Inputs
und erwartete Outputs definiere und die werden validiert??
Grüße
Laurin
Stefan Lieser
Welche Notwendigkeit hast du denn, extension methods zu mocken?
> Aber was sind FIT Tests??
> Wie sieht das konkret aus? Ich habe quasi ein Excel File wo ich Inputs
> und erwartete Outputs definiere und die werden validiert??
Schau mal http://fitnesse.org/FitNesse.UserGuide.TwoMinuteExample an.
Mit Fitnesse hast du ein Wiki in welches du die Tests schreibst. Dazu
kommt etwas Gluecode um die Tabellen mit deinem SUT zu verbinden.
Grüße
Stefan
Laurin Stoll
Danke für deine Antowrt :-)
> Welche Notwendigkeit hast du denn, extension methods zu mocken?
involviert und mich hätte halt interessiert wie man mit denen gut in
UnitTests umgeht. Und wie ich jetzt erfahren habe geht das wohl nur
mit Typemock.
> Schau malhttp://fitnesse.org/FitNesse.UserGuide.TwoMinuteExamplean.
> kommt etwas Gluecode um die Tabellen mit deinem SUT zu verbinden.
Danke.
Grüsse
Laurin