|
Demo Version
|
|
|---|
Download and try for yourself a fully working demo version, including sample apps and documentation. The only limitation is that the demo version only works inside the debugger.
|
|
Subscribe
|
|
|---|
Get It All for $50 USD:
WebPortal, ORMapper,
Source Code, All Updates
|
|
User Login
|
|
|---|
|
|
|
|
Wilson ORMapper Forums : Chat & Share : Unit Testing a Domain Model
|
|
|---|
| 3/9/2007 3:59:25 PM |
Hi everyone,
Just wondering what approaches you have used in Unit Testing your domain model classes, when using an o/r mapper like the WilsonORMapper.
Thanks,
David Martines |
| 3/10/2007 12:15:39 AM |
What approaches? Sorry, your question seems a little vague - I use NUnit to do testing of my domain model classes. What else do you want to know? Maybe some specifics would help.
|
| 3/12/2007 4:11:07 PM |
Sorry for the vagueness. I am referring to situations where domain model classes rely on infrastructure such as the ormapper. When I'm testing domain logic (not persistence logic) I want the unit tests to be able run without needing to connect to the database. |
| 3/14/2007 6:36:09 AM |
That's why I use the code generation framework I designed for WORM - I use the Service Locator design pattern for doing dependency injection, and it allows me to abstract the persistence layer in such a way that the business logic doesn't know which actual persistence mechanism is being used, it just calls out to a facade. It works quite well, actually.
The nice thing about it is, if I don't have any unit tests, it doesn't matter - but I can always add them later. Ideally, I would use TDD to get things done, but sometimes putting in tests later is all you can do, unfortunately.
Jason Bunting |
| 3/15/2007 2:22:12 AM |
Cool, that's the sort of thing I'm after. I actually have a similiar sort of framework where I define interfaces for a Repository and a Unit Of Work. I then create a worm implementation of those classes in a separate project, and use reflection to "dependency inject" the implementation that is specified in the config file (either the worm implementation or a dummy, in-memory implementation for testing.). All works well, up to a point. For basic CRUD stuff, the in-memory implementation works great in the test scenario. But when it comes to querying, it gets complex. It seems I would need an interpreter to make the opath queries find matching objects in an in-memory list. I see where you have an ISelectionCriteria interface which looks like you might have this handled, but I haven't looked at it closely.
David Martines |
| 3/15/2007 2:22:12 AM |
Cool, that's the sort of thing I'm after. I actually have a similiar sort of framework where I define interfaces for a Repository and a Unit Of Work. I then create a worm implementation of those classes in a separate project, and use reflection to "dependency inject" the implementation that is specified in the config file (either the worm implementation or a dummy, in-memory implementation for testing.). All works well, up to a point. For basic CRUD stuff, the in-memory implementation works great in the test scenario. But when it comes to querying, it gets complex. It seems I would need an interpreter to make the opath queries find matching objects in an in-memory list. I see where you have an ISelectionCriteria interface which looks like you might have this handled, but I haven't looked at it closely.
David Martines |
| 3/20/2007 4:22:12 PM |
Well, I don't care to unit test the capabilities of OPath - if I were to write a mock persistence manager that dealt with OPath queries, I would just hard-code expected subsets of the data rather than worry about writing something that parsed OPath to give me what I wanted.
For example, if the code I wanted to test looked like this (contrived pseudocode):
StudentCollection sc = StudentManager.GetAll("FirstName == 'Joe' && GPA > 3");
if(sc.Count > 0)
{
Console.WriteLine("Some 'Joe' has a GPA higher than 3.0!");
}
In my mock persistence manager, which is injected at runtime for unit testing, I might have something like:
public StudentCollection GetAll(string opath)
{
StudentCollection sc = new StudentCollection();
switch(opath)
{
case "FirstName == 'John' && GPA > 3":
sc.Add( new student object that matches the criteria );
sc.Add( new student object that matches the criteria );
sc.Add( new student object that matches the criteria );
break;
case "some other opath":
sc.Add( new student object that matches the criteria );
sc.Add( new student object that matches the criteria );
break;
etc.
}
return sc;
}
Hope that makes sense. Sure, this isn't perfect, and maybe a parser for OPath that works on in-memory collections would be nice, but who has time for that? Besides, isn't LINQ going to provide that for us? Sadly, I don't know enough about LINQ to say authoritatively, but I want to say that I think that is part of it.
|
| 3/21/2007 1:16:58 PM |
OK, I see now. I guess I didn't really understand the mocking principle before. Thank you very much for that example - it was very enlightening.
-David |
| 3/21/2007 4:35:36 PM |
There is one main caveat to my example, which is that there is the hopefully obvious dependency between the business logic which contains the OPath statement and the mock class which also contains it. Obviously you would want to ensure that not only to those match to ensure fidelity between the two, but that if they change you change the test data you provide as well.
If you are writing unit tests to check your business logic, you really don't care so much about how you got the data, per se, but if it meets your code's expectations so that you can test your processess which utilize the data.
Anyway, I am sure others might disagree, but I personally don't care to test things that are expected to work. That said, it sure would be nice if all of the .NET framework, and third-party libraries as well, included unit tests when shipped - then you would feel better about building entire apps on top of code that you know works, as indicated by the passing tests.
I am rambling now and have a splitting headache, so I think I am done. :P
|
|
|