jasmine-spec-prototypes - to allow overridable spec helpers and mixins in specs

[Brian Takita]

I created a monkey-patch on jasmine.Suite and jasmine.Spec that allows
method overriding in subdescribes and rudimentary mixins.

https://gist.github.com/2802890

I'd like to get people's feedback on this and would like consideration
on adding such functionality to jasmine core.

I tried to stick with javascript idioms, but maybe the api needs to be
different.

It could also use a bit more fleshing out. For example, I can see
support for `super` as being useful.

I'd love to hear everybody's thoughts.

Thank you,
Brian Takita

[Davis W. Frank]

Brian,

Thanks for putting this together to explain the idea.

We're of the opinion that using "this" between specs is a code smell. With Jasmine's current implementation - Jasmine uses that "this" heavily - specs can pollute/confuse Jasmine internals and it can be hard to chase down. We're considering cleaning this up and also move away from befores and its sharing the same "this".

You can accomplish the same thing by putting variables in the scope of the describe and sharing data that way. You do have to ensure that a before or after cleans up any context, but that's good practice anyway.

What are you trying to accomplish with this Mixin? Do you have a more practical example?

--dwf

--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To post to this group, send email to jasmi...@googlegroups.com.
To unsubscribe from this group, send email to jasmine-js+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jasmine-js?hl=en.

--
thx,

--dwf

[Brian Takita]

On May 27, 9:37 am, "Davis W. Frank" <dwfr...@pivotallabs.com> wrote:
> Brian,
>
> Thanks for putting this together to explain the idea.
>
> We're of the opinion that using "this" between specs is a code smell. With
> Jasmine's current implementation - Jasmine uses that "this" heavily - specs
> can pollute/confuse Jasmine internals and it can be hard to chase down.
> We're considering cleaning this up and also move away from befores and its
> sharing the same "this".

I understand your concern about using this. I'm not sure about the
conclusion that it is a code smell however.

RSpec has the same "problem" but, it's been more of a theoretical
problem than one that many people have run into. Have jasmine users
been running into this problem?

A solution, that doesn't relegate this to be an anti-pattern, is to
the using an internal variable is to prepend '__' to all attributes
that jasmine uses. That way, somebody would have to out of their way
to call something internal to jasmine.

I'm not necessarily married to using this, but it does seem like it
follows javascript's idioms. I'm open to modifications to the api as
long as template methods are in :-)

>
> You can accomplish the same thing by putting variables in the scope of the
> describe and sharing data that way. You do have to ensure that a before or
> after cleans up any context, but that's good practice anyway.

Actually I can't. In that strategy, the last setting of the local
variable wins. I updated https://gist.github.com/2802890 to
demonstrate. See variableFn.

I want to have template method overriding. That means the first level
beforeEach block calls a method that can be overridden by a lower
level describe. This allows cleaner describe hierarchies, easier to
read tests, and less duplicate code.

>
> What are you trying to accomplish with this Mixin? Do you have a more
> practical example?

The mixin would be an added bonus. Sort of akin to rspec's
it_should_behave_like. In the rspec implementation, a module is mixed
into spec object. That means its and helper methods. This is useful
when setting up contexts.

I don't have a practical example in Jasmine yet, because this
technique was not available :-)
>
> --dwf

[Brian Takita]

On May 27, 12:22 pm, Brian Takita <brian.tak...@gmail.com> wrote:
> On May 27, 9:37 am, "Davis W. Frank" <dwfr...@pivotallabs.com> wrote:> Brian,
>
> > Thanks for putting this together to explain the idea.
>
> > We're of the opinion that using "this" between specs is a code smell. With
> > Jasmine's current implementation - Jasmine uses that "this" heavily - specs
> > can pollute/confuse Jasmine internals and it can be hard to chase down.
> > We're considering cleaning this up and also move away from befores and its
> > sharing the same "this".
>
> I understand your concern about using this. I'm not sure about the
> conclusion that it is a code smell however.
>
> RSpec has the same "problem" but, it's been more of a theoretical
> problem than one that many people have run into. Have jasmine users
> been running into this problem?
>
> A solution, that doesn't relegate this to be an anti-pattern, is to
> the using an internal variable is to prepend '__' to all attributes
> that jasmine uses. That way, somebody would have to out of their way
> to call something internal to jasmine.

Another solution is to use "private" functions using closures. This
will guarantee people cannot access internal jasmine logic.
http://javascript.crockford.com/private.html

[Davis W. Frank]

re: hiding Jasmine internals, we're absolutely going to do something along those lines. We've not gotten to that re-work yet.

I'm still not understanding why you'd want to have this template method. Can you put together an example assuming Jasmine worked the way you want?

--dwf 

[Brian Takita]

On Sun, May 27, 2012 at 12:39 PM, Davis W. Frank
<dwf...@pivotallabs.com> wrote:
> re: hiding Jasmine internals, we're absolutely going to do something along
> those lines. We've not gotten to that re-work yet.
>
> I'm still not understanding why you'd want to have this template method. Can
> you put together an example assuming Jasmine worked the way you want?

I update the gist https://gist.github.com/2802890 with
purchase_flow_spec.js as an example where template methods are useful.

Mainly, it's when business logic starts to get intricate and there's
lots of nested describes and edge cases to test. If there's lots of
nesting, then it would be very hard to maintain a tests with a bunch
of duplicate setup, which I've had to do with jasmine specs in the
past.

[Brian Takita]

On Sun, May 27, 2012 at 1:03 PM, Brian Takita <brian....@gmail.com> wrote:
> On Sun, May 27, 2012 at 12:39 PM, Davis W. Frank
> <dwf...@pivotallabs.com> wrote:
>> re: hiding Jasmine internals, we're absolutely going to do something along
>> those lines. We've not gotten to that re-work yet.
>>
>> I'm still not understanding why you'd want to have this template method. Can
>> you put together an example assuming Jasmine worked the way you want?
> I update the gist https://gist.github.com/2802890 with
> purchase_flow_spec.js as an example where template methods are useful.
>
> Mainly, it's when business logic starts to get intricate and there's
> lots of nested describes and edge cases to test. If there's lots of
> nesting, then it would be very hard to maintain a tests with a bunch
> of duplicate setup, which I've had to do with jasmine specs in the
> past.

The example is when things start to have edge cases. In reality, there
can be a few more levels of nested describes to flesh out the various
edge cases. I'm sure I can concoct more sample domain complexity if it
would help illustrate the need for template methods :-)

[Brian Takita]

I'm sorry for being an snark. Basically, the case is I want to override a method that is called in a beforeEach in a parent describe.

It works well in my project (real world code as opposed to sample code). It's tough to make a sample because I need to make a sample with complex requirements.

Anyways, is this feature DoA? I really hope you include it as it would make Jasmine more powerful.

Thanks,
Brian

[Davis W. Frank]

As near as I can tell, this is the only request for such a feature. For these types of things, I'd rather see you make it available as an add-on and see if it gets traction. If there's a lot of momentum, then we're happy to revisit.

--dwf

[Brian Takita]

Ok. I just hope that this isn't a victim of the blub paradox.

I don't have much time to market it, so I guess I'll just leave it at that :-\

[Curtis Schofield]

Actually - I've noticed increasingly complex and nested describe blocks with many beforeEach - i miss having a let syntax for setting up my test variables.

The patch seems to address this in a way - it would make sense to me to have an amendment to this patch to wrap the this.prototype.function in a declarative - style 'let'

Ie 

let('thing',function(){});

Or

let({thing:function(){},newEvent:function(){})

Not sure what syntactical representation would make sense for let! Maybe 'set' instead of let.

--

Curtis J Schofield

BlazingCloud.net

"Creativity can solve anything" 

- George Lois 

  (source: art & copy)

[Brian Takita]

Awesome, you rock Curtis! I like let as well.

On my project, we tried set. I felt prototype was more "javascriptish", but at this point, I don't care what the api is as long as there's a consensus on method overriding.

I would like to also have super, but don't want to fight that battle.

I wanted to use let, but cringe as Jasmine's usage of global methods. Again, a battle I don't want to fight.