Scoping of assertion functions

[Ates]

Zach Carter raised a very good point in his recent post (http://zaa.ch/
past/2009/1/31/jsunity/) about jsUnity:

> The globally scoped assertions kind of bug me, but seem to be modeled after JsUnit style tests. Ideally, those assertions could reside in a module, making them as easy to use and safe to extend.

I completely agree. Things to consider are:

1. Decouple the jsUnity "core" from the assertion functions. Users
should be able to include any set of assertion functions that they
like.
2. Having a set of default assertion functions (would be nice).
3. The scope of the assertion functions. Global? Inside a closure?
Zach also suggested that function-type test suites can use a with(){}
to introduce a set of assertion functions into the test suite scope.

What are your thoughts?

[Ates]

Actually, thinking about this more, the downside of moving the
assertion functions out of the global scope are:

1. The user has to add a with() clause to the function-type test
suite. It's a bit of extra work and breaks the compatibility of the
test suite with JsUnit (whether this is important or not is another
issue.)
2. The with() trick can only be used with the function-type test
suites. There's no way to do this (or is there?) with object, array or
string-type test suites. There's no strict requirement that all of
these different types of test suites need to be there. I defined them
since they all got partially implemented as a consequence of
implementing the support for function-type test suites. Which one is
more important? Uncluttering the global scope or providing the users
with more than one convention for defining test suites?

Ates

[Ates]

2. Correction: Yes, there is a way for the user to add the with() with
all suite types, but requiring the user to do that is a bit ugly. One
thing that can be done is to stringize all test functions and redefine
them inside a closure that has the with(). Yes, I think I'm going to
give this a shot.

[Ates]

I've just committed a change where all the assertion functions were
moved into a defaultAssertions variable that gets exposed through
jsUnity.assertions (lowercase because it's a member that be accessed/
overridden.) The function-type suite parser adds a with
(jsUnity.assertions) to the generated runner function. To be able to
have the same implicit with() apply to all other suite types, they all
have to go through the same function compilation code path. Earlier
on, I was thinking of some messy-to-implement optimizations (in
generating the runnable suite object) based on the suite type (array
doesn't need parsing of function names, string already is the runner
function body, etc.) but now I'm abandoning them in favor of using the
with(jsUnity.assertions). Still, there will be some optimizations
based on the suite type but the code will be a lot more uniform.

[Zach Carter]

Hey Ates,

The caution I have about serializing functions is that you'll loose
the local environment they were defined in, like the value of local
variables defined outside of the test suite. Generally, any tricky
closure stuff could possibly be lost, though perhaps that is not good
practice in test writing anyway? Something to ponder; I realize the
function style tests are already serialized this way.

Though, another idea for people that really don't mind global assert
functions: they could easily introduce them to the global scope by
iterating over the jsUnity.assertions module and adding them to the
global object. jsUnity could even provide a helper method for this
(jsUnity.exposeAsserts() ?) Others could use explicit with(...) or
attach asserts to the test suite if self like jsUnitTest[1]
(this.assertTrue()), or even still, YUI style[2].

[1]: http://github.com/drnic/jsunittest/blob/b2898168fdd5a09adba67689e0e5fa20daa32ca2/src/test_case.js#L11
[2]: http://developer.yahoo.com/yui/examples/yuitest/yt-simple-example.html

[Ates]

Yeah, that's the bad thing about serializing/redefining the test
functions. I wonder if we should completely drop that (or simply don't
push it as the preferred method). That's dropping the function and
string type test suites and supporting only object and array. What are
your opinions on this?

I had thought the exact same thing about giving the option to expose
the assertions globally (or into any given scope) by using a helper
function. Something in the lines of "jsUnity.applyAssertions([scope])"
where scope defaults to the current scope. We can vote on the most
suitable name for this :)

Ates

On Feb 2, 1:31 am, Zach Carter <Zack.Car...@gmail.com> wrote:
> Hey Ates,
>
> The caution I have about serializing functions is that you'll loose
> the local environment they were defined in, like the value of local
> variables defined outside of the test suite. Generally, any tricky
> closure stuff could possibly be lost, though perhaps that is not good
> practice in test writing anyway? Something to ponder; I realize the
> function style tests are already serialized this way.
>
> Though, another idea for people that really don't mind global assert
> functions: they could easily introduce them to the global scope by
> iterating over the jsUnity.assertions module and adding them to the
> global object. jsUnity could even provide a helper method for this
> (jsUnity.exposeAsserts() ?) Others could use explicit with(...) or
> attach asserts to the test suite if self like jsUnitTest[1]
> (this.assertTrue()), or even still, YUI style[2].
>

> [1]:http://github.com/drnic/jsunittest/blob/b2898168fdd5a09adba67689e0e5f...
> [2]:http://developer.yahoo.com/yui/examples/yuitest/yt-simple-example.html

[Zachary Carter]

On Mon, Feb 2, 2009 at 1:12 PM, Ates <ates....@gmail.com> wrote:
>
> Yeah, that's the bad thing about serializing/redefining the test
> functions. I wonder if we should completely drop that (or simply don't
> push it as the preferred method). That's dropping the function and
> string type test suites and supporting only object and array. What are
> your opinions on this?

It could still be an option, but I agree, probably not the preferred method.

>
> I had thought the exact same thing about giving the option to expose
> the assertions globally (or into any given scope) by using a helper
> function. Something in the lines of "jsUnity.applyAssertions([scope])"
> where scope defaults to the current scope. We can vote on the most
> suitable name for this :)

Let's go with that, or attachAssertions.

[Ates]

I've added the attachAssertions functions. So, right now, the core
consists of 2 "members" and 2 functions:

- defaultAssertions - the set of default assertions
- assertions - set to defaultAssertions by default; can be overridden
by the user
- attachAssertions - adds the properties of assertions to the given
scope (or the default scope)
- run

On Feb 2, 4:55 pm, Zachary Carter <zack.car...@gmail.com> wrote: