March 11, 2008
Test Code Is Production Code, And Test Coders Are DevelopersA common objection that I hear to automating UI tests is that user interfaces change.
Which means that they end up having to rewrite a lot of their test code. And we all know what a pain in the beehive that is.
But, as developers, we also know that change is inevitable, and we therefore know that we have to structure our code so that it's as easy to change as possible.
Let's be clear about this: the economics of testing are such that the only practical way to get high levels of assurance as our code grows and evolves is to automate our tests. That is the inescapable reality, just as it is with unit tests and integration tests. If we do them by hand, then it takes much, much longer and costs much, much more to test our software comprehensively, covering all the nooks and crannies where bugs might be hiding. Manual testing does not scale.
So, much as we might hate the idea, we must have automated test code, and that automated test code must be able to accomodate changes to the UI, because the UI will change - and often.
In code design, we find that we can minimise the "ripple effect" where changing one part of the code forces us to fix a whole bunch of other code that is directly or indirectly depending on it by depending more upon abstractions and generalisations - things that are less likely to change.
In UI design, buttons and sliders and drop-downs and other widgets are quite likely to change. If our test code depends directly on the names and types of UI components, then that's where our pain comes from: we are writing test code that is highly dependent on things that are very likely to change.
We can make our life easier by hiding these low-level UI details behind some kind of high-level abstraction, through which the tests drive the user interface. For example, we could create a facade for the UI. Indeed, some desktop applicqations actually follow this sort of design. Microsoft office application APIs, for example, have some kind of Application class which exposes UI-independent methods like "NewDocument()" or "Copy()", "Paste()" etc.
So when we decide to turn the Submit button into a link, for example, or change the order of the columns in the Orders list view, our test code won't be affected.
More generally, we need to remind ourselves that test code is still code. And that, if we want high test assurance - which we do, I assure you! - than the maintainabiluty of our test code will be a critical factor in the maintainability of our production code. So we must treat the design quality of test code as seriously as the quality of the code it's testing.
In short, test code IS production code. Which is why people who write automated tests - using whatever tools - need to be first and foremost good developers with an instinct for code quality.
The importance of the role of Test Developer is slowly dawning on software organisations around the world, but there's a massive shortfall of ppeople able or willing to perform it. Realistically, you must be a developer before you can become a test developer, since learning how to create high quality code takes longer to master than learning how to write effective tests. That's not to denegrate the discipline of software testing: anyone who's read Robert Binder's book on Testing Object Oriented Systems will know that, if you wanted to, you could dedicate a lifetime to understanding testing. But, let's be honest now, it takes longer to learn how to code from scratch than it does to learn how to break code*.
But I suspect in 5-10 years' time, as test-driven development becomes more popular and teams become more ambitious in their testing efforts, test developers will be in great demand and will be able to command high salaries. I see them becoming as important as architects are viewed as today. Maybe more so, since they actually add value on a project ;-) (Only kidding)
* Is that my inbox I can hear filling up again?
Posted 10 years, 9 months ago on March 11, 2008