Javascript != Internet Explorer

I had this funny experience today with this little piece of Javascript:

function Redir(sAcceptUrl, orderId)
{
document.location.href = sAcceptUrl + "?orderid=" + orderId;
return false;
}

The function was called by a button's onClick-event like this:

input id="theBigRedButtonGoesWild" onclick="Redir()" type="button

This worked fine in IE but not in Firefox.... Firefox just posted to the same page and didn't care very much about the document.location.href change - What the hey ???

It turned out that when using this little function in Firefox you have to use the return value of the Redir() function in order for the Firefox event model to NOT perform a postback - like this

input id="theBigRedButtonGoesWild" onclick="return Redir()" type="button">


It has something to do with the fact that a button in Javascript is actually always a submit-button and inherits it's behaviours from a world which posts back if nothing else is being dictated. IE's event model is - well - different ;o

This was just a quick one - I am on vacation for 3 weeks starting in about 5 hours (first thing on my todo-list: Go to the parent's house and mow their lawn because they are on vacation...) so this blog will be on hold until I am back from work

Regards Kristian

RSS feed

For Your Information Only: I have burnt my feed on FeedBurner so please change the URL to this feed in your favourite RSS reader to this one:

http://feeds.feedburner.com/JustAnotherSoftwareEngineer

Thanks - and a nice weekend to you too :o)

Regards K.

Antipatterns exception testing

During my first encounters with Test Driven Developement (TDD) I adopted the ExpectedException attribute and used it heavily when coding - that is: I focused a lot on testing for every exception written in the code.

I have come to the conclusion during the last few weeks that my testcases didn't provide very much value if you test heavily for exceptions. There are a few bulletpoints to mention here:

• Tests written for testing errorconditions on general exceptions (ArgumentNullException etc) are not important. You should write exceptions for ArgumentNull etc. etc but I don't test for them anymore. Focus your testing on things you can assert instead - a test which throws an error will fail the test so even if you don't write an explicit test for the error condition your test will still fail you if the error occurs. Never ever aim for 100% code coverage - if you do you are walking a deathmarch.
• Business value exceptions are on the other side very important to write tests for. If you have custom exceptions classes which you throw when i.e. a business rule fails to validate you should write a test which succeeds only if the error is thrown. This provides business value: You know that your business logic works because you get your expected exception thrown
• If you throw exceptions in your code WITHOUT explaining what went wrong I will hunt you down and shoot you in the legs. Not very pedagogic indeed but exceptions are only useful with a meaningful description of what went wrong. You are giving the consumer of the exception no data to help figuring out what went wrong.
  

Which best practices on this issue do you reccommend to others?

Rhino + VS debugger == WFT?

We have used the MVP pattern lately in my recent project to increase testability and decouple the UI from our business logic. To enhance our testing environment we have begun using Rhino Mocks and it is an overall satisfying experience even though I am still having a hard time "getting it right" when writing tests.

I want to share with you one of the "What The F***" experiences I had just a few minutes ago: One of our mocking tests failed. Well - insert a few breakpoints and fire up the debugger. And then it happened: For every time I ran my test I had errors on different lines in my source code... Most of the times I had a NullPointerException but at other times the Rhino framework threw mysterious errormessages at me...

I was a little scared to see a unittest behave like this for twenty minutes and really had no clue what was happening but my collegue was able to solve the puzzle once I asked around for a little help. What had happened was that in my MVP Presenter I had set up an mock of my view and some expectations for different properties to be called during OnLoad. They should be called just once so when you start using your debugger's Quickwath on those properties you "use up" the quota of expected calls. You are actually fulfilling the expectation you just set up when quickwatching a property in a test with expectations set Rhino-style... And when the code afterwards tries to execute the code you intended the expectation to test for your test fails because you only set your property up for being accessed just once.

Lesson learned today: When a test which uses mocking fails you - clear all breakpoints and try again. It actually solved the mystery and I was able to fix the initial cause of the error within a few minutes.

Firefox - not just another browser

Disclaimer: Lots of people have written this post before me. Don't come back and tell me that you haven't heard this one before ;o)

*****************************************************************

I am usually very relaxed when it comes to the tools I am using - I use whatever suits my needs and strive not to be very religious about who created them and if I am using the newest version or not.

I have used Internet Explorer for quite a while (always actually). I have tried a few browsers over the years the latest one being Maxthon which was recommended to me by one of my former collegues. It never hit the spot mainly because I didn't give it a real try - I didn't spend enough time to see what extra value it could provide me because it seems to be a quite successful browser variant.

However - I must admit that the new Firefox 3 is amazing mainly because it is so freaking fast. It feels like I just had my computer upgraded to a bigger processor and doubled my RAM. This is the first browser I have begun to use as frequently as Internet Explorer - simply because it is better than it's competitor. The addins are also extremely powerful - they have been around for years but the vast amount of plugins written for Firefox is simply amazing. If you want to do something whatever it is - searching, social networking, image grabbing, resizing, debugging... Somebody is likely to have written a plugin for Firefox which enables you to do whatever you want to quicker and easier than before you discovered the plugin.

Speed + extensibility = I love it. IE isn't a bad browser at all but they should really be careful not to be become a has-been. Jugding by these figures IE still wins the socalled "browser war" but they are about to loose precious market shares unless they saddle up and start producing something of similar star quality.

Regards K.