Tom Anderson said:
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).
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.
[ SNIP ]
Yes, we haven't been using any coverage tools. It'd be something i'd like
to try. I'd really like to have ways of knowing whether our tests are any
good. Quis custodiet ipsos custodes?
tom
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.
AHS