Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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