Skip to content

Loading…

Namespacing #38

Closed
wants to merge 1 commit into from

2 participants

@webnesto

I was going to give jasmine a try and noticed that it wasn't fully namespaced, so felt the overwhelming OCD need to wrap it. I was working with the built download files, so it was a cakewalk to just wrap it in a closure, attach everything to a scoped var and return it. Talked to Davis Frank, and they asked for/about a pull request of the mods, so I checked out your source. Due to the code separation, wrapping the entire base in a closure is not the easiest (or best) route, so I did a little effort towards namespacing/scoping.

Mainly wrapped every major player who needed any privately scoped variables in a closure, and scoped those vars/functions so as to really be private. Made for duplicated private "undefined" vars, but that's how it has to be when you're compartmentalizing code. In base.js I made all the global vars properties of jasmine to avoid muddying the global namespace. example of how to make it still readable in your specs:

jasmine.describe("foo", function () {
    var _ = jasmine;
    _.it("should still be easy to read", function () {
        //some code
    });
});

If this is a route you'd like to take your code base, there's a good bit of continued work that could be done to improve, though this seems to work just fine as is.

Hope it's useful for you. If you're interested in further strategies on how to JS namespace within a complex build system, let me know. I've spent a lot of time thinking on the matter and have some pretty decent ideas.

unknown * namespaced jasmine and wrapped functions using private-by-conventio…
…n variables/functions in closures to allow for true scoping.
c36cf6e
@webnesto

Had an afterthought on writing readable tests, could always use the evil "with" statement:

with( jasmine ) {
    describe( "foo", function () {
        it( "should be easy to read, but might be slower to execute", function () {
            //some code
        });
    });
}

I haven't really looked into the effect this would have on the test time reporting, since with-statement lookups are going to take longer than a scoped var, but unless you're doing performance testing (and I'm not sure jasmine is the right tool for that), this would be an option.

@webnesto

Just realized that I goofed in the spacing, by stating
var _jasmine = this;
Instead of
var _jasmine = {};

which assigned _jasmine to the global scope instead of a local scope as desired.

@infews

We made a conscious decision not to use with. Not many folks like it.

We have been talking about doing something with namespacing in an upcoming release. But its a ways off - many other things to do first.

@webnesto

I wasn't suggesting that you use the "with" statement internally, it was merely a suggestion for test-suite writers to make the namespaced jasmine easier to use.

Personally, I won't be using the main repo until it is fully namespaced. I'm involved in rather large application development oft-times with many external library dependencies (due to integration of third party work) and I can't afford to include a testing tool that is muddying up the global namespace if for no other reason than that being a potential failure point/conflict for each pointer.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Dec 19, 2010
  1. * namespaced jasmine and wrapped functions using private-by-conventio…

    unknown committed
    …n variables/functions in closures to allow for true scoping.
Something went wrong with that request. Please try again.