Subject: Re: Testing JavaScript code in gitweb.

From: Andrew Sayers <[email-masked]>
Date: Sun, 20 May 2012 10:50:52 +0100

On 19/05/12 22:44, jaseem abid wrote:
<snip - broadly sensible analysis of the testing options>
> 
> I would prefer BDD style Jasmine for testing. The argument against it
> was that It cant be run from terminal (node.js). That will add a new
> dependency and hence cant be done. And as Andrew mentioned earlier, I
> think its better to run JavaScript tests in a real browser itself,
> because that's where it ultimately needs to run. He also mentioned
> that TDD would be a nice way to go [7]. I guess BDD will be ok in the
> context.

I think it would be clearer if I said "TDD is worth developing an
opinion about".  Unit tests are very valuable, but the way you go about
writing them is fairly personal - some people find TDD just right, some
like BDD, some want to chase the next technique, and some of us just
muddle through.  If BDD works for you, great!  If you try it and don't
like it, think about the problems you had and what would be a more
productive approach for you.

One important thing we haven't discussed yet is measuring code coverage.
 I often fall into the trap of thinking very hard about some parts of my
code and not paying enough attention to others.  Then I write loads of
tests for the things I've been obsessing about and ignore the things
I've been ignoring.  Guess where the bugs appear :)

Measuring code coverage lets you avoid that trap by showing what's
covered by tests and what isn't.  I've never actually done test coverage
in Javascript, but JSCoverage[1] and JesCov[2] are worth a look.  I'd
particularly recommend having a look at the JSCoverage example for
jQuery - it seems like they don't regularly check coverage, as there are
several obvious gaps in their tests.

	- Andrew

[1] http://siliconforks.com/jscoverage/
[2] http://jescov.olabini.com/
[3]
http://siliconforks.com/jscoverage/instrumented-jquery/jscoverage.html?test/index.html