Tom Anderson said:
news
[email protected]... [ SNIP ]
By hand? No automated testing of the complete app through its web
interface?
The idea of using automated tests for the web GUI has been bruited,
but in our environment it would be unrealistic.
Interesting. Can i ask why?
The original writers of the app - they converted a mainframe legacy app
over to a J2EE one - never saw fit to write web tests, only a reasonably
comprehensive set of JUnit tests. Also, the pages have been more of a
moving target. Now that there are completely different people adding to,
and fixing, the application, none of whom had a hand in writing it
originally, and there aren't many of us, we have no time to write a
sufficient body of web tests (and there would have to be hundreds).
Aah, i see. Fair enough. I had the idea you meant technical reasons, but
organisational reasons are just as good!
They'd be nice to have...nobody denies that. We were also left with no
documentation...what saves us is the fact that we're surrounded by
people who know what the app is supposed to do in the business sense,
since it's not like the rules for motor vehicles changed all that much
in the transition from legacy to J2EE. But web tests would help document
those business rules, and also assist maintenance programmers who have a
hard time reproducing errors in what is quite a complex front-end.
Having had to put some thought into my replies, I'm getting more convinced
that we really need to have a good set of web tests. Our human testers are
fantastic, but it takes many weeks to completely regression test the
application. The JUnit tests miss most of the business logic, quite frankly,
since that is linked into the interplay of JSF managed beans and session
beans. The fact that all of our thousands of JUnit tests pass has to be held
up alongside the fact that there are hundreds of listed defects.
So code coverage linked with a good set of *web* tests is, I believe,
the way to go for a J2EE app. The JUnit tests are still necessary, but
by themselves they don't help much.
My company has been working on maintaining a large ecommerce site for a
few years - since long before i joined. When we inherited it, it had no
tests. The approach taken was to follow the traditional XP rule that you
can't work on something unless you have a test to tell you if you've
broken it, and a test to tell you when you've completed your task. In
other words, incrementally building a test suite as work was done on the
code. Since the initial contract was for some large-scale redesign of the
site, this led to fairly wide coverage.
Something similar might perhaps work for you. Initially, it will involve a
lot of overhead, but once you have a critical mass of tests built,
building more is greatly aided by reuse of code from existing tests - all
the boilerplate of logging in, going through the typical workflows,
validating key pages, etc. It never becomes trivial (i spent half a day
yesterday writing one test), but it can become fairly effortless.
tom