https://bugzilla.wikimedia.org/show_bug.cgi?id=44299
--- Comment #22 from Krinkle <[email protected]> --- Moving this bug back to MediaWiki>Unit tests. (In reply to comment #20) > Is there still a reason to run the test from Selenium? I agree with S, it is useful to run them both from QUnit (on Special:JavaScriptTest) and from Selenium (on actual pages as part of the wider integration test). (In reply to comment #21) > > It would be great if a test in the latter would load every registered module > > (currently 391 on enwiki!) and see if any end up in an error state. > I tried this and it doesn't work, some of the modules are conflicting skins > and others fail by design if they're loaded on an inappropriate page. The > page > looks bizarre after you try it :) Indeed, they're not supposed to be loaded unconditionally. Failure is by design in that case. Also, even if they were changed to fail gracefully when loaded in the wrong environment, the test would be moot. It would run the code and load the classes in memory, but it still won't actually execute individual methods until they are interacted with. You'd have to know how to interact with it and trigger every code path. The only thing achieved by indiscriminately loading all code is catching syntax errors, which we already catch pre-commit with jshint. And if you want to catch it on code that isn't linted for some reason, run jshint on it (checkout all of mediawiki/core and mediawiki/extensions/* and run jshint, if you really want to, though that's probably going to give a lot of false positives since it includes upstream code. Best to just let Jenkins/jshint handle it). -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
