On Mon, Dec 20, 2010 at 3:43 PM, Peter Higgins <da...@dojotoolkit.org>wrote:
> 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
>>
>>
Heh, incidentally, I released a simple proof of concept for such pragma's
over the weekend. It's completely library agnostic but it's not exactly a
complete package :) But maybe it helps. See http://pcd.qfox.nl
I guess I should add a simple textarea so you can try for yourself. I'll do
that later tonight :)
- peter
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
