views:

163

answers:

5

I have never done any testing in javascript. I know, I know. But the reason is that I've never built big javascript applications before, so I've never seen any reason for getting into testing.

But now I figured it's about time to get crackin'.

The only problem is that everywhere I go, every testing framework seems to rely on the fact that people already know how to test with javascript, they only focus on why their testing framework is better than the next.

What I would like, is a very basic introduction to testing with javascript. When is it neccessary? What should you test? How should the tests be set up? How often do you test? You know, just very, very basic stuff.

So any links to texts or videos will be highly appreciated (:

Thanks.

edit: Just to make clear: What I'm looking for is introductions to testing, not specific frameworks. Because right now, I don't even know why I should test...

And if there are any books on the subject, that would be even better.

2nd edit: I found a really nice video from Nicholas Zakas on Yahoo! Theatre, where he explains TDD practice for javascript first, then explains how to use YUI testing to achieve those goals.

+1  A: 

I would recommend JSpec. It's a Behavior Driven Development framework and also comes with Screencasts.

Peter Krenn
A: 

JsUnit

JsUnit is a Unit Testing framework for client-side (in-browser) JavaScript. It is essentially a port of JUnit to JavaScript. Also included is a platform for automating the execution of tests on multiple browsers and mutiple machines running different OSs.

rahul
+1  A: 

Unit testing in javascript, while awesome, is probably not the bundle of deliciousness that unit testing is in most other languages.

The main reason for this is that javascript is so dependent on what browser it's running on - plus asynchronous behaviour is so ubiquitious it can be a bit daunting to get started with it.

Here are few things that might help get you started, just don't expect an incredibly easy entrance, nor the immediate gains that other languages tend to get.

John Resig did an excellent writeup on the limitations of testing in javascript that might be a decent place to start.

Here's a video on starting to write tests for javascript BDD in fireunit.

Steerpike
+2  A: 

I find Javascript unittesting often necessary on XHR (AJAX) calls. You write unittests to assert that the response is what you expect it to be. Test-driven development on the server and client side can help you corner the problem- are enough parameters being sent? Is something getting mangled on the way? Is the serializer behaving the way I expect it to? Tests are set up just like in any other environment- reduce and simplify it to isolate the problem.

For very basic stuff, I recommend that you start debugging with Firebug (setting breakpoints and the like), and then move on to unittesting with Selenium.

Ramkumar Ramachandra
Nice. Thank you. I've already gotten to the point where I use breakpoints in Firebug, I just never thought of that as "testing" per say, just debugging. I understand that testing is more of a preemptive strike against bugs, while breakpoints is a way of curing (:
peirix
Right. Personally, I found it quite easy to move from setting breakpoints in Firebug, writing small assert statements, and then gradually moving into Selenium. Interactive debugging with Firebug is feasible when the application is small enough. As the application becomes larger, you'll get frustrated stepping through the same functions over and over again- personally, that is when I realized the importance of unittesting. To make sure that the rest of your program's working when you're debugging one specific function.
Ramkumar Ramachandra
As an added bonus, Selinium is a Firefox add-on too just like Firebug.
Ramkumar Ramachandra
+2  A: 

Unit testing in general allows you to build up a battery of small tests that verify fine-grained bits of your code, especially edge cases. This is especially useful in Javascript where your application needs to run the same way on different browser platforms.

Creating a suite of such tests allow you to ensure that changes you make today don't break code you wrote yesterday (or a month ago).

For example, you may have a part of your application that walks all the DOM nodes in the document to find and bind to nodes it cares about. You decide to optimize this, perhaps by using the jquery selector. If you have a test that all the possible nodes can be found properly, you can quickly see if the changes you just made broke anything, on any of your target browsers.

You can also "fake out" XmlHttpRequest interactions with the server using various frameworks - this allows you to verify that your client code can react properly to all sorts of results and errors coming back from your backend.

Basically, as with other languages, unit tests in JS allow you to automate answering the question "did I just break anything" with these changes?

levik