2. Testing JavaScript: Why
• The usual unit testing benefits, but also:
• Improving browser compatibility
• Catching regressions in your code
• Catching browser regressions – very
important!
3. Testing JavaScript: How
• Many test frameworks out there, none of them as
advanced and convenient as Test::Harness
• All suffer from JavaScript restrictions on file
system access, IO, etc.
• Jasmine from Pivotal Labs is touted to be one of
the best, which I think is true
• But it’s also a pain to use: lots of boilerplate
HTML just to run a spec, have to manage it all
manually, etc.
4. Solution: Test::WWW::Jasmine
• Take Jasmine test specs, run them in Selenium
controlled browser
• Generate all the boilerplate HTML and
JavaScript required to run the specs
• Parse Jasmine output, convert it to TAP
• Each describe() is a test, each expect() is a
subtest
• Test diagnostic printed out with diag(), native
to TAP::Harness
6. Example: test output
1..6
ok 1 - use Test::WWW::Jasmine;
ok 2 - Got object
ok 3 - Right object isa Test::WWW::Jasmine
ok 4 - Parsed all css scripts
ok 5 - Parsed all js scripts
1..1
ok 1 - expectation 1
ok 2 - expectation 2
ok 3 - expectation 3
ok 4 - expectation 4
1..4
ok 1 - should run tests
ok 6 - jasmine multiple test
7. Local testing
• Automated testing is good, but it’d be cool if
we could run the same specs locally while
developing?
• Enter jasmine.html: JavaScript/HTML spec
runner that supports the same format as
Test::WWW::Jasmine
• Runs in browser locally, displays neat HTML
(Jasmine default, actually)
• Will be released soon, somewhere
9. Test::WWW::Jasmine warts
• Work in progress, released to CPAN yesterday
• Needs local (NFS anyone?) HTTP server with
writable htdocs/something
• Needs browser and Selenium installed
• No headless testing yet (does it make sense?)
• Maybe bundle jasmine.js along
• Maybe run local tinyish HTTP server and serve
specs off it