Testing JavaScript code in gitweb.

Testing JavaScript code in gitweb.

[jaseem abid]

Hi,

Over the last few days, I explored ways to test the JavaScript code in
gitweb, and this is what I came up with.

Tests can be split into 2 major categories.

- Tests in the console.
	Pros
		- Can stick to the existing TAP, t/95xx testing pattern.
		- Easier integration with the existing test system.
	Cons
		- Will need a run time environment for JavaScript. Major ones are
node.js[1], spidermonkey and Rhino. All add *huge* dependencies to
git.
		- [IMP] The code is ultimately going to be run in a browser. Its
best to test in the same environment.
			From [2]:
				> JS test suites generally run in the browser because knowing that
your  tests pass in some sane command-line compiler tells you nothing
about  how it will be mangled by IE (or in rare cases, other
browsers).

- Tests in the browser.

	Pros
		- Test in the same environment where the code is going to be run.
Andrew mentioned this [2]
		- Ideal way to test in all those browsers out there across platforms
and versions effectively.  Can host the test page publicly with
gitweb, so that people can test it quickly in their won browsers and
report bugs.
		- No new dependencies.
		- Great libraries available.

	Cons
		- Wont go with the existing system.
			There are no tests for JavaScript now[3] . This would definitely
make it only better.  The perl code can be tested in the existing
manner and the JavaScript code can run in browser with no issues.
			Jakub mentioned this wont be a problem [4]
			
- Here are a few frameworks I considered for the task.

- Jasmine.
	BDD style testing. Current priority #1.
	Runs in the browser. Benefits mentioned above.
	Powerful and feature rich. A good tool for the task.

- node-tap [5]
	Needs node.js as previously mentioned.  This is the one that is
officially recommenced[6].

- JSdev
- TestSwarm
- JSTestDriver
- sinon.js

	Rejected by Jakub as not suitable after discussions[4].

-Qunit

	Priority #2. Runs in the browser.


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.
Jakub almost agreed with browsers after the previous discussion thread[8].

I would love to hear from all about testing JavaScript code in the
browser with Jasmine.

More on testing frameworks[9]


1 : http://nodejs.org
2 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7423349.html
3 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7420271.html
4 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7423442.html
5 : https://github.com/twada/qunit-tap
6 : http://testanything.org/wiki/index.php/TAP_Consumers
7 : http://colabti.org/irclogger/irclogger_log/git-devel?date=2012-05-13#l57
8 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7432237.html
9 : http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript


-- 
Jaseem Abid
http://jaseemabid.github.com

Re: Testing JavaScript code in gitweb.

[Andrew Sayers]

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

Re: Testing JavaScript code in gitweb.

[chaitanya nalla]

Hi,

Even JSTestDriver has the feature of code coverage. Here is the link
:http://code.google.com/p/js-test-driver/wiki/CodeCoverage

JSCoverage also works great in my opinion.

Re: Testing JavaScript code in gitweb.

[Kevin]

On Sun, May 20, 2012 at 11:50 AM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:
>
>
> 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.
>

The differences between TDD and BDD aren't that big. BDD is almost the
same as TDD, but with a stronger language description.