Comments on: Getting FIT

By: Robert Watkins

Robert Watkins — Fri, 26 Aug 2005 09:28:23 +0000

I haven’t used Selenium, so I can’t really compare and contrast. However:

# Javascript popups: JWebFit uses JWebUnit, which uses HttpUnit. HttpUnit lets you build custom “responders” to JavaScript dialog, which should let you do what you want. It’s not exactly trivial, but of course, once you do it once, you can re-use it.
# Test breakages: FIT, unlike JUnit, keeps running when it hits broken assertions. All broken assertions are highlighted, so you can easily see which one broke. Working out why it broke can be a little tricky, though. In the case of JWebFit, you do get error output, so it depends on how much effort you put into that.

By: Vijay

Vijay — Wed, 24 Aug 2005 23:32:52 +0000

I have been using selenium for a lot of my projects and a couple of the drawbacks that I faced were:
1) Javascript popup windows: Selenium has some limitations with these and we are not able to “click” a specific button to test the different paths that the application might take based on different choices.
2) When the test fails at a particular table row (command), it is quite difficult to find out the exact line number where it failed – especially if the test has lots of commented out rows (which are typically just comments, but sometimes are also the results of changing functionality/bugs that were found). In the latter case, these test rows would ideally be uncommented at a later time (as soon as the developer fixes the bug).

So, my question: does using either of the above mentioned packages bypass these concerns in an easy way?
thanks,
Vijay

By: Software is too expensive to build cheaply...

Software is too expensive to build cheaply... — Fri, 13 May 2005 22:33:58 +0000

Learn in the quiet times

I had a comment lodged on an older article recently. The poster was complaining about the poor quality of the JWebFit sub-project of JWebUnit. In particular, he was complaining about how it meant their project wasn’t delivered on time. There’s…

By: Robert

Robert — Fri, 13 May 2005 22:14:29 +0000

Sagar, it’s not _my_ project. If you’ve got feedback to give, please give it to the project maintainers.

However, I’m not sure why the lack of documentation cost you so much time. It’s not a large project, you can read the source code easily enough, and work out pretty much everything it does in a few hours. I actually spent more time writing this article than I did working out how it worked.

What I probably should do is restore the examples that got lost when my site had to be rebuilt.

Oh, and if you committed yourself to using a tool that you didn’t know on a time-sensitive project, then frankly that was your own mistake. You can’t learn under pressure – you need to have slack time to come to grips with new tools, so you can experiment and play with it. _Then_ you can apply the tool to a time-sensitive project.

By: sagar

sagar — Fri, 13 May 2005 20:38:08 +0000

The documentation was terrible. We couldnt get much help out of it. Please add some meaningful and informative documentation about Jwebfit. We had fits because we could’nt complete our project in time, due to lack of help from documenetaion

By: Robert

Robert — Mon, 20 Dec 2004 22:09:43 +0000

Thanks for the comment, Sam.

I haven’t looked at Selenium, but it does sound interesting. One issue for me would be how I run them from my build scripts; firing up an IE browser, pointing it at a URL, and capturing the result wouldn’t be non-trivial.

Also, in my particular environment, our build servers are Win2K with IE6, but the client desktops are NT 4 with IE 5.5. Thus, tests that use the IE6 browser wouldn’t find bugs that show up in IE 5.5. Programing to the DOM model, which Rhino requires, helps reduce these bugs (at the cost of making the Javascript less readable). I’m actually in the process of such a conversion at the moment.

By: Sam Newman

Sam Newman — Mon, 20 Dec 2004 20:36:50 +0000

You *might* want to look at selenium, which is like fit but runs inside the browser. As it is actually rendering it will run slower, however it is also using the browser itself rather than some abstract notion of the browser. We had problems with Fit at my current client where the Javascript implementation in fit itself (Rhino) differed from the javascript implementation in IE, such that we had to change our Javascript code. Selenium would of resolved that issue for us – it also has the benifit that you can step through your test to see what’s happening at each step, which can help you find the problem more quickly. For more info see: http://selenium.thoughtworks.com/index.html, for online demos: http://selenium.thoughtworks.com/demos.html