Two types of jsUnit tests

I am a big jsUnit fan. I can't imagine what JavaScript development would be like if that tool did not exist. We all know that code without proper unit test coverage is legacy code. It is a time bomb waiting to go off in the hands of the developer that touches it next.

Over time I have noticed a pattern in my jsUnit usage. I usually wear one of two testing hats when writing tests:

• The browser compatibility hat. Most developers know how to do things in Internet Explorer, and Gecko-based browsers. Those differences are widely known and people are used to writing code that works. Now, throw in browsers like Opera, Safari, and even Mac IE. The sheer number of things that can go wrong in any one browser becomes overwhelming. The only solution to that problem is to wrap your problematic DOM objects' access into JavaScript objects, and cover those with unit tests. Run those tests against every browser that you need to support.
• The implementation hat. This one is just plain test-driven development (TDD). I TDD the code that I need to write to complete a story. That code avoids accessing DOM objects like hell. You want to test it separate from the user interface, and of course decreasing dependencies makes the code easier to maintain. "But my date picking logic requires a text box DOM object?!" JavaScript's dynamic nature comes quick to the rescue – pass in any object with a value property:
  

  
  picker.GetDate({ value: "12/25/2004" }); //Last Christmas I gave you my heart…

Try not to wear both hats at the same time! You risk high coupling to the underlying DOM that will make browser compatibility hard to test. The code will be hard to change too – what if you want to change that hand-crafted list of links to a more accessible and standards-compliant ordered list?