Functional Test Updated
After evaluating the previous named contenders for webtest tools, the winner was … none of them.
It dawned upon us that the MaxQ way of doing this, ie. recording tests, really is not the way to go, ever. What you’re really doing is testing the server from a HTTP perspective, without testing button clicking and stuff. For example, all hidden fields must be specified at every request. If you have anything Javascript based you still have no clue if this works after having these funtional tests.
On the other hand, using anything based on HttpUnit actually mimics a webbrowser, so you can click buttons and not have to worry about hidden fields. And yes, Javascript is handled.
jWebUnit is based on HttpUnit, but it has a rather limited API, for example you cannot find a button by its name to click it. We came to the conclusion that it was easier to build our own API on top of HttpUnit.
We also decided to implement the same API in a mock implementation ? la the way it is described in “Testing XP”. This way functional tests can be run very quickly on development machines and the more time consuming remote HTTP tests are done on the integration machines (Yes, we have several, one for every deployment OS).
September 25th, 2003 at 9:36
Have you tried Jameleon or TestMaker ? Could any of these be an alternative ?
—-Trond
September 25th, 2003 at 14:53
Have you tried WebTest Canoo?
I spent sopme time evaluating it yesterday, and although its not junit based, it is a set of ant tags. I like the fact that the test authors only need a little xml knowledge rather than any programming experience.