How I Unit Test in jQuery
I created a function that will add arbitrary html to the DOM and remove it immediately after my test has run. This is what it looks like in use:
And this is what comprises the function:
It is important to note that errors leave garbage divs behind. This is definitely a work in progress. :)
If you're looking for the short and quick, that was it. If you're wondering why I'm doing this read on. (You can also view the live typed version here: http://ietherpad.com/ep/pad/view/Ek6pNOcyjv/latest)
How Brittle Is Your jQuery?
When you need to test your HTML DOM manipulations which of the following best describes your approach:
- Just don't test it. You use Javascript templating and keep the interactions simple enough that it's low risk and has never proven to be a huge issue.
- Write a javascript unit test, write your jQuery code, then verify your jquery interactions using jQuery to test the DOM
- Write some jQuery, load the web page, and manually test it each time you make a change
- Write your web page and test it using Selenium after the fact
- Just don't test it. It would be valuable for you but you just don't have the time.
These are the most common strategies in my experience. The top two are strategies I have been known to employ. In one project I have been very successful in leveraging a very event oriented MVC-like templating technique that hasn't bitten me yet for net testing my code. At Cheezburger however I have been going with the technique of more QUnit tests.
I have found not testing or using Selenium to be the wrong ideal.
Why Test Javascript At All?
Realistically if we're professionals we always test our code. The controversy in testing is usually related to whether or not we automate it. Why automate anything? Everything is so easy once you understand how to do it. If you just take the time to understand the code (by grabbing your nearest warm body) you won't need tests because it is just that easy.
Because I understand that I am falliable, that I miscommunicate even when I say things exactly as they are and I mean them (ain't human perception a bitch?), because I don't want my team to have to take the time to ask for my opinion. It feels great on the ego.. that's a huge behaviour smell right there.
Why Avoid Selenium?
It's an issue of short and tight feedback cycles. To be perfectly fair, I'm sure there are ways of using Selenium such that one can have very tight feedback loops. That's not how I do it though and I've not yet experienced anyone else who has used the tool in that way either... just sayin. When I am delving into unknown code it is much too expensive to wait a couple seconds for the server to start up and then another several seconds for the other tests to run for every change I make.
Having said that, I love Selenium for code that is too difficult to get under unit tests. It's great to have a way to give me a pretty high degree of confidence that I haven't broken anything.