From: Andrew Sayers <andrew-git@pileofstuff•org>
To: jaseem abid <jaseemabid@gmail•com>
Cc: "git mailing list" <git@vger•kernel.org>,
"Jakub Narębski" <jnareb@gmail•com>
Subject: Re: Testing JavaScript code in gitweb.
Date: Sun, 20 May 2012 10:50:52 +0100 [thread overview]
Message-ID: <4FB8BE7C.8050306@pileofstuff.org> (raw)
In-Reply-To: <CAH-tXsDif9YOrkEcj7AdRfn6gvLx4mj4+SKCB4GzyW6QJpx=9A@mail.gmail.com>
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
next prev parent reply other threads:[~2012-05-20 9:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-19 21:44 Testing JavaScript code in gitweb jaseem abid
2012-05-20 9:50 ` Andrew Sayers [this message]
2012-05-20 10:00 ` chaitanya nalla
2012-05-22 5:58 ` Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB8BE7C.8050306@pileofstuff.org \
--to=andrew-git@pileofstuff$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=jaseemabid@gmail$(echo .)com \
--cc=jnareb@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox