I've often run on this problem. Now I am working on a team of 4 and we built a lot of stuff. We are still finishing somethings and making changes. The problem is that those changes can (and most probably will) cause interface/business to crash.

We do not have any kind of map that show us something like "If you change the DataSource of this table the code X on that table will have to change. And on the screen X the list will have to be changed".

Unit tests can help validate business rules, what about interface business? Can it also validate code bound to the interface? Should we rely only on unit tests? And how deep does it have to be to prevent the code breaking because of changes? Should we use some other approach as well?


You need (preferably automated) integration / system tests too, apart from unit tests, precisely to verify that changes like your example don't break existing - seemingly unrelated - functionality in your system as a whole.

UI testing is much more difficult than unit testing, but there are tools which can help at least somewhat. For web pages, e.g. HttpUnit or Selenium are recommended by many. If you tell more about the type of your system, we may be able to give more precise advice.

An intermediate path may be to write subsystem tests, which are technically like bigger unit tests, possibly involving the DB too. DbUnit is a tool which can help you in this. Subsystem tests may allow you to verify dependencies / assumptions like the one you describe, so that if you change the data source of table T, some test for code X will fail, forcing you to update that code too.

The underlying problem is that you apparently don't understand how your system works. This is sadly common for legacy apps, but your descriptions seems to suggest that this system has been built by your team from the start - in which case there is a fundamental problem with the way you work. You must absolutely learn to document dependencies within your system - and you must also work on reducing and controlling these dependencies. Pay attention to coupling and cohesion in your architecture, in order to divide your system into independent modules/components which only affect each other in well defined ways.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.