I am running a development architecture team that is fairly focused on bolstering testing practices among a number of disparate development teams. One of those teams is using Contentmaster for relatively simple data mapping/transformation.
There are a set of rules that document the mappings that should be performed. Today, there isn’t any automated way of testing that the mappings are “correct.” We suggested that the team test individual mappings by creating a simple testing framework and then testing the transformation rules one by one before every deployment, but they have the typical concerns:
- How do I know if my test or the mapping is wrong?
- What happens if someone changes a mapping and my test breaks?
- How am I supposed to justify all the time I need to spend in order to make the test cases?
- What if a test yields a false negative (i.e., passes when it shouldn’t)?
Can you help me answer some of these questions. I am familiar with this kind of testing for custom development projects, but I’m having a harder time answering when it comes to data manipulation like this.
1 – How do I know if my test or the mapping is wrong?
As of today, How do you know the mapping is right? Someone will need to investigate if this is a problem. It’s better that a unit test fails and someone can investigate now, instead of passing it to QA or even the client.
2 – What happens if someone changes a mapping and my test breaks?
They aren’t your unit tests, they’re the unit tests. He who breaks the build, fixes the build. Everyone should be running all the unit tests before checking in and they should be run automatically on every check-in by Hudson or similar.
3 – How am I supposed to justify all the time I need to spend in order to make the test cases?
I personally have found TDD to disturbingly faster than normal development. Even if it was just the same speed, the amount of time saved by finding bugs at the developer/pre-QA level will pay for itself almost instantly.
Don’t waste time writing unit tests to make sure working code works. Only add/update a unit test if you are: 1) changing functionality, 2) Adding new functionality, 3) fixing a bug.
Plus later on, when you go back and refactor you will know that you have not broken the code severely.
4 – What if a test yields a false negative (i.e., passes when it shouldn’t)?
This is a fact of life. Bugs will get missed. Just because the unit test can miss bugs, doesn’t invalidate unit testing. I mean, if QA missed a bug would you fire the QA department? The purpose of unit testing is to reduce the number of bugs which escape the development team. This way, QA can concentrate on more serious issues.
If this happens, the only thing you can do is go back, update the unit test and then fix the code.
Unit testing isn’t a silver bullet, but it is invaluable in development.