3 ms·
I'd be interested if one of these articles on modularity also addressed testability. For example, the IIFE pattern in the article: (function(window, $, undefin
by bazzargh 14y ago
I'd be interested if one of these articles on modularity also addressed testability. For example, the IIFE pattern in the article:
(function(window, $, undefined){
//do some work
}(window, jQuery));
If instead of immediately executing this function, we kept a reference to the function, then reference it, the function can be supplied with mocks for testing.
Obviously there's an issue that you'd pollute the global namespace with this named function. So what's the best practice there?
- ufo 14y agoI don't think you need to go through all the trouble. Some thing like the following should be enough: oldJQuery = jQuery; jQuery = mock; //Run module jQuery = oldJQuery; Remember that IIFE's are basically equivalent to variable definition and assignment. The only reason we even have to go through the trouble of using them is due to JS not having block scope.
- bazzargh 14y agoYeah, I'm aware I can do that, but it gets a bit painful for code that is stateful & executes on load (like IIFE does). You end up having to write a separate test script to run in a separate process for each test case...way slower than if you can isolate the module and 'restart' it in a closure for each test. A different approach that might work for me would be to subvert require.js, so that it pulls in mocks. I see there's other people thinking along the same lines: https://github.com/tigbro/requirejs-factory-plugin https://github.com/tigbro/requirejs-factory-plugin