Take the 2-minute tour ×

I'm not quite sure if I'm missing something really obvious here but my searches on this topic aren't returning results of use to me. I have recently gotten more into unit testing and using mock objects. This is all well and good for testing objects in isolation but, in a complex Spring MVC application that is interacting through AJAX with a lot of Javascript code I sometimes run into issues such as a value being passed in that is not what it needs to be and causes something to break. Of course it still fulfills the type, such as being a String, but it may be null, which would cause something to break down the line.

I figured if I could do something like below within an actual class of my application (not in an isolated unit test) then it could be useful. Sort of like a debug mode but instead its running the app as a unit test I would run it regularly and be able to interact with it (manual testing) and, if a bug occurs that violates one of the tests I placed in there it would tell me. I realize I can do this with System.out.println but I tend to use this too much, maybe sometimes, so it can be hard to sift through all the outputs to pick out things like this, so would be better, I think, if it had the regular Junit GUI dialog brought up when something occurred.

String somestring
if (somestring != null) {
boolean checkSomestring = true;
else {
boolean checkSomestring = false
assertEquals(checkSomestring, true);

I may have rambled a bit, I'm guessing there is a way to do this but it is eluding me at the moment, would appreciate any advice. Thanks

share|improve this question

1 Answer 1

up vote 0 down vote accepted

We've just got a little ASSERT(bool shouldBeTrue, string failureMessage) function in our javascript. When it fails it sends a logger request... just a GET request with url-encoded arguments: dateTime, machineName, currentCocument, and the failureMessage. The web-server just writes it to a log-file. Then a "tailing job" (a korn-shell script based on "tail -f") periodically (every minute, from memory) picks-up the message-lines and emails them to the developers-email-group for the system. The same kit is used on several systems.

Don't ask me about the details; I'm "the unix guru"... and a self-confessed bunny when it comes to javascript. The guy who wrote it is still around though; so I could (next week) ask him if he minds it being published on the net.

I think the whole setup is pretty neat. Most of the time we just ignore the assert-mails (I have an outlook rule which sends them all straight to the deleted bucket); except when we're testing something... This way we get to use each others unit testing of the GUI to detect "breakages" in stuff we wrote. I also keep an eye on them for a couple days after each release.

BTW: Once upon a time we tried automated web-app testing. We spent a small fortune on it, until we figured out that were using our good software to test our crappy test-scripts... and we basically gave-up in disgust. But that was years ago, and I believe that things have improved dramatically in this area, so it might be worth having another look; atleast for the "critical" functionality of the system.

Cheers. Keith.

share|improve this answer
Sorry to hear about your automated test debacle. Could you expand briefly on what tools you used, and why it went wrong? –  Tom Anderson Apr 25 '11 at 9:17
@Tom: We used a beast called QARun, simply because we already had a (very expensive) licence for it, from a VB project. It just wasn't at all suited to testing a web-client... so we wrote a meta-language on top of QA's primitives, which had it's own bugs, as did/does QARun. The whole thing was just too brittle. A UI change could take a day to code, and then a week to update all the test scripts which touched that form/component. It was a loosing battle. Basically: It was too hard to change. I guess HtmlUnit (or something) would've been a LOT more cost effective. –  corlettk Apr 25 '11 at 10:04
Ah, a sorry tale of woe. I think we've all been through our own version of that inadequate tool/layer on top/descent into madness story at least once. We use HTMLUnit for web interface testing, and our experience has been better than yours sounds (more of a shallow glide into madness). But still not perfect, because its javascript handling is a bit wobbly when pushed to do complex things. If i started again now, i'd use WebDriver. I hear that has problems of its own, though. It's a tough game, that's the bottom line. –  Tom Anderson Apr 25 '11 at 22:07

Your Answer


