About a year ago, we were using jWebUnit, which is an API built on HttpUnit — which in turn is very similar to HtmlUnit. We used it in conjunction with DbUnit to load the database tables before the test and verify them after. It worked really well. We had tests that could verify the operation properly manipulated the database, and could check the structure of the HTML returned.
We went away from it mainly because functional tests could only be written by programmers with that method, and with JMeter we could have someone a systems analyst or a tester write the functional tests. Using the proxy recorder available in JMeter let a user click through the test and replay it. JMeter could load the DB and check it based on CSV files, instead of XML. In the end I think the flexibility is a little less, but the number of people who can help get the work done has increased.
It is nice to see someone actually going through all that ‘trouble’ to do full testing. I’ve used WebTest (based on HttpUnit) to script some web apps and it worked pretty good, especially when we had complex web forms spanning pages. However I’ve never seen using JMeter in conjunction with DBUnit to do functional testing and that sounds like a pretty interesting approach. I may have to try that out sometime.
We’re actually just using the JDBC piece of JMeter to load up and check the DB. So we’re not using DBUnit with JMeter, though I agree it sounds interesting…
Seems to me, in a web envirnment where things change all the time, the more time you spend developing a test that relies on underlying database schema and the api of the web actions, the more likely that test will be obsoleted sooner and become unmaintained.
I think the idea of recording clicks/inputs on web pages is a lot more promising in terms of continued usage of the test.
I haven’t worked in a situation where someone besides myself was responsible for testing the code I had written though. That could possibly change my opinion on the subject.
Very nice site. Keep up the good work.