Bit of a rant this so just delete if you've got better things to do!
Be very careful with Nhibernate unit testing, the mock in memory database
does not perform in the same manner as MSSQL / Oracle / Sybase . for very
simple queries it will perform as expected for more complex joins it'll
cause you grief. In my last project we worked on 2 week turn arounds, 3 days
of that time the entire team was tasked to debugging the unit tests!
Three things that we learnt from that experiance.
1. Don't let a checkin to source control without all the unit tests
passing. ( check in and test after is fine but if the automatic build fails
the developer has 30 mins to fix the problem or we roll back to the last
known version that worked ) . Use Automatic Builds, on a dedicated build
machine that the entire team can see the result, the screen up high so other
teams can critisize when the build isn't working.
2. Don't test multiple layers of the application, Test the public
interfaces, if the method requires an List<Customers> create some and pass
it to the test. Some that should pass and some that should fail.
3. Cross Test , Get another developer to sit with the test writer and come
up with other scenarios.
>From looking at the Unit test your making way too many unit tests for each
step.
Write 2 helper functions GoodPlan , BadPlan try to signoff on both.
Write one test each to validate Acceptable entries for your other tests.
ex
try{
planController.AddSignOffContact(PlanDummy.InitialState,
ContactDummy.GoodContact);
} catch (Exception e){
Assert.Fail(e.message);
}
try {
planController.AddSignOffContact(PlanDummy.InitialState,
ContactDummy.BadContact);
Assert.Fail("Signed of with BadContact");
} catch ( InvalidSignOffContactException){
}
Try to keep mocking to an absolute minimum, it's completly useless to verify
that your mocks work as expected when you've got a database upgrade that
requires lots of DAL changes that break your unit tests. If you mocked the
entire datalayer, you'll be rewriting the tests and the mocks for days to
come. Don't mock the SMTP server, post it to an internal address find out
now if you bring the smtp server to it's knees, if all your connections are
closed correctly and you've treated every last RFC Status code reply
possible. A dummy smtp server that dumps all incomming mails to null , will
process millions of messages per second. a real server with a database ,
queue, latency , network and spam blockers might have a few problems with
your v1 @gra style email service.
Don't get me wrong, I like unit testing, but I don't belive it's the holy
grail of programming / development.
Both of these will pass badly written unit tests.
return string.format("{0} {1}",goodie.lastname ,goodie.firstname);
or
return (goodie.lastname == "Green") ? "Green Grahame" : "Odie Bill";
Unit testing is a tool to prevent regression, using it to write code, as in
TDD, when not all the team has 10+ years experiance working to
excelent standards of quality, will lead to spagetti code that works up
until the first bug report after the team has finished the development. I've
been there trust me. ;)
.02c
Dave.
On 1/4/08, Paul Cowan <[EMAIL PROTECTED]> wrote:
>
> I guess the best way to learn is from somebody experienced in the art.
>
> Either that or looking at an existing open source project with unit tests.
>
> I think I will explore the Nhibernate tests.
> They do contain db calls but very few considering it is an ORM.
>
> With most things, I generally have to go through the pain barrier before I
> fully understand the art.
>
> [EMAIL PROTECTED]
>
>
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
