On 30/03/12 12:05, Jakub Narebski wrote: > But even if the JavaScript tests would have to be run in browser (like > most of all of them seems to), having any automated test for gitweb's > JavaScript code would be a very good idea. > > P.S. I wonder how JavaScript-scriptable Veracity DVCS solved that... 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). IMHO, the best thing to do with JS unit tests would be to make them easily available from gitweb. Then when someone reports a bug, you just ask them to run the tests in their browser - the pattern of errors will quickly show you that e.g. their AdBlock filters are getting a bit overexcited about all these `git add`s it can remove (that sort of thing was a frequently-reported problem at my last job). Obviously it's good to run tests automatically too - you might want to consider writing tests with QUnit[1] and automating them with Selenium[2]. The former is designed to be appealing to human eyes and trivially testable with the latter (although I'd expect other suites to include the necessary <div>s with the necessary id's too). I haven't used the Perl interface myself, but I'm sure you could make some TAP output with WWW::Selenium pretty easily. - Andrew 1. http://docs.jquery.com/QUnit 2. http://seleniumhq.org/ -- 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