Mark Needham

Thoughts on Software Development

TDD: Testing mapping code

with 4 comments

I’ve previously written about some of the aspects of the mapping efforts that we’ve done on recent projects and what we’ve found from our testing (or lack of) around this type of code is that somewhere along the line you are going to have to check that you’re mapping these values correctly, be it in an automated test or just by manually checking that the correct values are being sent across our integration points and into other systems.

Writing unit tests around mapping code is certainly one of the areas of testing where it feels like there isn’t that much value in doing so – after all we are just copying data from one data structure to another, what could possibly go wrong?!

While I would certainly agree that in this case we are not using the tests to drive the design of our code, I think they are still very valuable for helping us to ensure that our specific bit of mapping code is doing what we expect it to.

Let’s say we have data flowing across our application like so:


We get the data from the UI and we need it to end up being sent to the service. Along the way there are a few different places where data could get lost and from (painful) experience I’ve found that if we aren’t testing that all our data is being mapped then we will forget to map something and then we will have the fun job of debugging end to end trying to work out where it got lost.

I would certainly relax the notion of taking small steps a bit when doing this type of testing otherwise it can get immensely frustrating – maybe write the tests for a set of similar fields and then writing the mapping code rather than creating the test -> code cycle individually for each one.

These tests can end up getting quite difficult to read so an approach we’ve been trying is to setup the test data in a TestFixtureSetUp at the top of our NUnit test fixture and then creating just the assertions for similar sets of fields in each test. I think it’s working reasonably well even though maybe it goes against the convention of the way you would typically use NUnit.

We’re still got higher level tests around this code and while they’re useful they don’t help us zoom into the point of error that easily so the humble unit test still has a part to play!

Be Sociable, Share!

Written by Mark Needham

April 2nd, 2009 at 11:11 pm

Posted in Testing

Tagged with ,

  • I can’t help but wonder if a good tool (or DSL) would be able to solve a general version of this problem.

    It seems like the core of this problem is that we’re unable to express the problem succinctly using our existing language/toolset (NUnit).

    It’s not complex for a human to define the proper mapping (say by drawings some arrows between two boxes on a sheet of paper), but it is complex (or just seems that way) to do so in NUnit.

  • The problem I guess is that there tend to be subtle differences between the two represntations of the data that we are mapping between so you always end up needing to explicitly state these differences.

    Would be cool if we could find a good way to do it though!

  • Pingback: TDD: Balancing DRYness and Readability at Mark Needham()

  • Pingback: Domain Driven Design: Conformist at Mark Needham()