Testing JavaScript code in gitweb.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]