February 12, 2008

...Learn TDD with Codemanship

Test-driven Object-Relational Persistence

Chugging through a small NHibernate example, where the goal is to demonstrate how object-relational mapping can fit into a test-driven apporach to development (and all it implies), I'm thinking about the issue of coverage and granularity of tests.

I like to ensure that application logic and persistence are completely seperate concerns. As such, I write two sets of tests - one to test that my application works logically without persistence, and another to test that my domain objects are persisted (saved and retrieved) correctly.

In previous projects where I've rolled up my sleeves and worked as a developer - and I think every software architect should do that at least once a year to keep their advice relevant and practical - I feel we've been burned by lack of test assurance in the object-relational mapping itself.

Namely, we thought that we could get away with being not as rigorous with our TDD when it came to persistence - we thought we were getting something for free!

These days, I prefer to build up my mappings as incrementally and rigorously as any other code. And I flesh it out as the need for certain persistent types arises, rather than doing it all in one go.

And for those little chunks of the domain model, I break it down in to a list of things that need testing (i.e., a unit test list) that I think will give me adequate test assurance. And I follow good unit testing practices, keeping each persistence/mapping test isolated from the others - rather than creating one huge object graph and persisting the lot, which is what I used to do.

Take this little domain model: I can work my way through it, testing that each type of object and its fields are saved and retrieved correctly, and then each reference to other object types (including collections) one at a time in seperate, independent unit tests.

To get coverage, I'm interested in walking all the way around the object graph along every navigable relationship. When I miss something, it usually shows up much quicker this way, and when something breaks, I can pin it down much faster because of the smaller granularity of the tests.

Indeed, I'm finding that O-R persistence is a lot less hassle when you tackle it in small, testable chunks like this.

Posted 10 years, 5 months ago on February 12, 2008