{"thread":{"id":"30566","subject":"Testing JavaScript code in gitweb.","startedAt":"2012-05-19T21:44:55Z","lastAt":"2012-05-22T05:58:15Z","messageCount":4,"participants":["jaseem abid","Andrew Sayers","chaitanya nalla","Kevin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"191743","messageId":"CAH-tXsDif9YOrkEcj7AdRfn6gvLx4mj4+SKCB4GzyW6QJpx=9A@mail.gmail.com","threadId":"30566","inReplyTo":null,"subject":"Testing JavaScript code in gitweb.","fromName":"jaseem abid","fromEmail":"jaseemabid@gmail.com","sentAt":"2012-05-19T21:44:55Z","receivedAt":"2012-05-19T21:44:55Z","isPatch":false,"sender":{"key":"jaseemabid@gmail.com","avatar":"https://gravatar.com/avatar/8b0432c96e4d3c8a9a96c9961ee842df7b7a869744da9c25187a51a992eabd81?d=mp&s=160"},"body":"Hi,\n\nOver the last few days, I explored ways to test the JavaScript code in\ngitweb, and this is what I came up with.\n\nTests can be split into 2 major categories.\n\n- Tests in the console.\n\tPros\n\t\t- Can stick to the existing TAP, t/95xx testing pattern.\n\t\t- Easier integration with the existing test system.\n\tCons\n\t\t- Will need a run time environment for JavaScript. Major ones are\nnode.js[1], spidermonkey and Rhino. All add *huge* dependencies to\ngit.\n\t\t- [IMP] The code is ultimately going to be run in a browser. Its\nbest to test in the same environment.\n\t\t\tFrom [2]:\n\t\t\t\t> JS test suites generally run in the browser because knowing that\nyour  tests pass in some sane command-line compiler tells you nothing\nabout  how it will be mangled by IE (or in rare cases, other\nbrowsers).\n\n- Tests in the browser.\n\n\tPros\n\t\t- Test in the same environment where the code is going to be run.\nAndrew mentioned this [2]\n\t\t- Ideal way to test in all those browsers out there across platforms\nand versions effectively.  Can host the test page publicly with\ngitweb, so that people can test it quickly in their won browsers and\nreport bugs.\n\t\t- No new dependencies.\n\t\t- Great libraries available.\n\n\tCons\n\t\t- Wont go with the existing system.\n\t\t\tThere are no tests for JavaScript now[3] . This would definitely\nmake it only better.  The perl code can be tested in the existing\nmanner and the JavaScript code can run in browser with no issues.\n\t\t\tJakub mentioned this wont be a problem [4]\n\t\t\t\n- Here are a few frameworks I considered for the task.\n\n- Jasmine.\n\tBDD style testing. Current priority #1.\n\tRuns in the browser. Benefits mentioned above.\n\tPowerful and feature rich. A good tool for the task.\n\n- node-tap [5]\n\tNeeds node.js as previously mentioned.  This is the one that is\nofficially recommenced[6].\n\n- JSdev\n- TestSwarm\n- JSTestDriver\n- sinon.js\n\n\tRejected by Jakub as not suitable after discussions[4].\n\n-Qunit\n\n\tPriority #2. Runs in the browser.\n\n\nI would prefer BDD style Jasmine for testing. The argument against it\nwas that It cant be run from terminal (node.js). That will add a new\ndependency and hence cant be done. And as Andrew mentioned earlier, I\nthink its better to run JavaScript tests in a real browser itself,\nbecause that's where it ultimately needs to run. He also mentioned\nthat TDD would be a nice way to go [7]. I guess BDD will be ok in the\ncontext.\nJakub almost agreed with browsers after the previous discussion thread[8].\n\nI would love to hear from all about testing JavaScript code in the\nbrowser with Jasmine.\n\nMore on testing frameworks[9]\n\n\n1 : http://nodejs.org\n2 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7423349.html\n3 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7420271.html\n4 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7423442.html\n5 : https://github.com/twada/qunit-tap\n6 : http://testanything.org/wiki/index.php/TAP_Consumers\n7 : http://colabti.org/irclogger/irclogger_log/git-devel?date=2012-05-13#l57\n8 : http://git.661346.n2.nabble.com/GSOC-Contributing-to-git-tp7420040p7432237.html\n9 : http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript\n\n\n-- \nJaseem Abid\nhttp://jaseemabid.github.com\n"},{"id":"191756","messageId":"4FB8BE7C.8050306@pileofstuff.org","threadId":"30566","inReplyTo":"CAH-tXsDif9YOrkEcj7AdRfn6gvLx4mj4+SKCB4GzyW6QJpx=9A@mail.gmail.com","subject":"Re: Testing JavaScript code in gitweb.","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-05-20T09:50:52Z","receivedAt":"2012-05-20T09:50:52Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 19/05/12 22:44, jaseem abid wrote:\n<snip - broadly sensible analysis of the testing options>\n> \n> I would prefer BDD style Jasmine for testing. The argument against it\n> was that It cant be run from terminal (node.js). That will add a new\n> dependency and hence cant be done. And as Andrew mentioned earlier, I\n> think its better to run JavaScript tests in a real browser itself,\n> because that's where it ultimately needs to run. He also mentioned\n> that TDD would be a nice way to go [7]. I guess BDD will be ok in the\n> context.\n\nI think it would be clearer if I said \"TDD is worth developing an\nopinion about\".  Unit tests are very valuable, but the way you go about\nwriting them is fairly personal - some people find TDD just right, some\nlike BDD, some want to chase the next technique, and some of us just\nmuddle through.  If BDD works for you, great!  If you try it and don't\nlike it, think about the problems you had and what would be a more\nproductive approach for you.\n\nOne important thing we haven't discussed yet is measuring code coverage.\n I often fall into the trap of thinking very hard about some parts of my\ncode and not paying enough attention to others.  Then I write loads of\ntests for the things I've been obsessing about and ignore the things\nI've been ignoring.  Guess where the bugs appear :)\n\nMeasuring code coverage lets you avoid that trap by showing what's\ncovered by tests and what isn't.  I've never actually done test coverage\nin Javascript, but JSCoverage[1] and JesCov[2] are worth a look.  I'd\nparticularly recommend having a look at the JSCoverage example for\njQuery - it seems like they don't regularly check coverage, as there are\nseveral obvious gaps in their tests.\n\n\t- Andrew\n\n[1] http://siliconforks.com/jscoverage/\n[2] http://jescov.olabini.com/\n[3]\nhttp://siliconforks.com/jscoverage/instrumented-jquery/jscoverage.html?test/index.html\n"},{"id":"191757","messageId":"CACeyogeMi4K-+j8pR0yKWeeJ1nu1Mca2Y+OPAetK-07cYFQKQQ@mail.gmail.com","threadId":"30566","inReplyTo":"4FB8BE7C.8050306@pileofstuff.org","subject":"Re: Testing JavaScript code in gitweb.","fromName":"chaitanya nalla","fromEmail":"nallachaitu@gmail.com","sentAt":"2012-05-20T10:00:21Z","receivedAt":"2012-05-20T10:00:21Z","isPatch":false,"sender":{"key":"nallachaitu@gmail.com","avatar":"https://gravatar.com/avatar/c9a4123cd12065ef283d9e90fe2425fd98b8217acb0ef20ad6c2529b9d692e62?d=mp&s=160"},"body":"Hi,\n\nEven JSTestDriver has the feature of code coverage. Here is the link\n:http://code.google.com/p/js-test-driver/wiki/CodeCoverage\n\nJSCoverage also works great in my opinion.\n"},{"id":"191879","messageId":"CAO54GHBgCczesZ6=9GtPZUWuWdmG_1eqCF3ak0Ff5Wgukd2TaA@mail.gmail.com","threadId":"30566","inReplyTo":"4FB8BE7C.8050306@pileofstuff.org","subject":"Re: Testing JavaScript code in gitweb.","fromName":"Kevin","fromEmail":"ikke@ikke.info","sentAt":"2012-05-22T05:58:15Z","receivedAt":"2012-05-22T05:58:15Z","isPatch":false,"sender":{"key":"ikke@ikke.info","avatar":"https://gravatar.com/avatar/60a0d08eeccb16914fdbfc7f3441548dc827dc436d5c6900ec6600e274e53c5b?d=mp&s=160"},"body":"On Sun, May 20, 2012 at 11:50 AM, Andrew Sayers\n<andrew-git@pileofstuff.org> wrote:\n>\n>\n> I think it would be clearer if I said \"TDD is worth developing an\n> opinion about\".  Unit tests are very valuable, but the way you go about\n> writing them is fairly personal - some people find TDD just right, some\n> like BDD, some want to chase the next technique, and some of us just\n> muddle through.  If BDD works for you, great!  If you try it and don't\n> like it, think about the problems you had and what would be a more\n> productive approach for you.\n>\n\nThe differences between TDD and BDD aren't that big. BDD is almost the\nsame as TDD, but with a stronger language description.\n"}]}