17 07 2008
Sometimes integration tests are more important
There are some cases when integration tests are more protective than unit tests. Of course, there is no reason to compare these two kinds of tests but if we have to write them we have to set priorities and think what problems may arise during development. One special case when it is important to have integration tests early in place is when we are using O/R-mappers.
Errors in mapping files, database and data differences in business logic of classes and corresponding database tables are time consuming to track, debug and solve. These issues may raise unexpectedly for younger programmers as they often don’t think "too far". When we have tests in place for this kind of problems we are able to detect and solve these problems faster.
Suppose you have some beginner programmers in your team (or some thunderheads who have lived with chaos in their mind right after they were born). One of those guys writes mapping files for O/R-mapper. Some other guy creates database objects like tables, views and stored procedures. And somebody writes business classes and their validation logic. Three persons – three points where things may go wrong.
When everybody is done the tests are performed. Everything seems to be correct in the scope of first release. Now customer gets notice that he or she or it (in the case when customer is UFO) can test the system. After five minutes customer sends screenshot with nasty server error telling that mapper is not able to perform delete operation. How and why this problem came suddenly?
Okay, under special conditions there were some rows added to table that is topic of next iteration. Because this table seemed therefore not so important for beginners they just created it and added some basic mappings but not cascading operation rules. In the database there are relations but no cascades defined because customer wanted to be able to use different databases. Why tester noticed nothing? Because tests related to this one table were topic of next iteration.
Okay-okay, I already hear the voices in internet through my network cable screaming that no normal company has such a problems and other blah-blah-blah like this. But hey, don’t forget that we are only human beings and we are very able to make mistakes and forget important things.
How to avoid problems like this
If you want to be correct and forward-looking developer you will write a load of integration tests or if you are lazy then you will write one big test. In both cases you try to do the following:
- Check out if you can insert objects. Test if you can create and save new object without errors. After inserting you have to test if all data you wanted to save is really saved or not.
- Check out if you can update objects. Test if you can save changes made to objects data with out errors. And also check out if changes were really saved.
- Check out cascade deletes. Add couple on rows on every table and try to delete top level object of each cascading branch.
Of course, there are much more things one may find protective and add to this list, but these three tests are the basic ones you should try out.
Searching problems in mapping files and database is time consuming activity. It is better to create mappings and database objects correctly on the first time. This way you can save a lot of time for another important tasks in project.