We have a "build system" we use for production code. In many of the
places we have this same situation we use "build pragmas" to ensure the
exposed reference is removed in production. eg:
myns.module = (function(){
var internal = true, otherinteral = {};
//>>excludeStart("debugging", true);
myns.exported = internal;
myns.exported2 = otherinternal;
//>>excludeEnd("debugging");
// or whatever
return {
foo: function(){
return !!internal
}
}
})()
Then the unit tests check against the intentionally/temporarily exposed
public members, though they are removed after being processed. nothing
in the module actually uses the myns.exported* stuff.
The pattern matching exists I know in Dojo and RequireJS builder tools,
just regexp based so should be easy to replicate in any deploy process
you have.
hth
~phiggins
On 12/20/10 9:28 AM, Michael Allan wrote:
Hi All,
We're trying to improve our processes and overall code quality at work by using
TDD for all new Javascript code, while simultaneously retrofitting tests to our
existing js codebase. We use a single global variable as a namespace within
which multiple sub-modules are defined, mostly following the Revealing Module
Pattern.
The problem we've struck is that the private helper functions within each
module can't be accessed from outside the closure for unit testing. We could of
course rely solely on our end-to-end tests to ensure correct behaviour, but
we're striving for more comprehensive coverage than that. Alternatively we
could expose all of these helper methods so that they can be properly tested,
however that defeats one of the primary benefits the pattern, namely
encapsulation. I'm loathe to do sacrifice one benefit for the other, and
ideally want both.
The only other alternative I can think of is to modify the files at build time,
perhaps exposing the private methods via a temporary test API object or by
removing the outer containing function which constrains their scope. Of course,
that would mean that we'd then be releasing a version of our code different
from the one we'd tested ... which sort of defeats the purpose.
Any thoughts or experiences you have to share would be greatly appreciated. I'm
a relative novice at TDD, so don't hesitate to mention anything you think seems
obvious. Likewise, I'm only a third of the way through Christain Johansen's
excellent book ... so feel free to tell me to at least finish that before
asking such things, if appropriate ;-)
Cheers,
Mike
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
