Home/ Questions/Q 4541192
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T15:11:44+00:00

I’m not quite sure if I’m missing something really obvious here but my searches

  • 0

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

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0