buster-jasmine adapter/extension

131 views
Skip to first unread message

Matt Fysh

unread,
Aug 13, 2012, 6:51:03 PM8/13/12
to buster...@googlegroups.com
I recently began to move all my projects over to BusterJS, but hit a few roadblocks with using buster's spec model.
For example, a toBeUndefined matcher does not exist, and I can't seem to find a simple way to test for not just an error, but the error message itself.

I thought of modifying all my test cases but then realised the benefit of a buster-jasmine adapter (in the manner of jasmine's jsTestDriver adapter). There are many advantages to this:

1. Quickly and easily allow specs to run on BusterJS
2. Maintain a familiar BDD syntax
3. Access to Jasmine plugins
4. Add Jasmine users to the BusterJS community, always a bonus!

I've got the Jasmine side of the adapter figured out - this is a matter of creating a new JsApiReporter and adding it to the runner, then listening for spec, suite and runner results.

Now I can't seem to find a way to get these results into Buster. Would anyone here have any idea where I should begin looking? I'm currently snooping around the buster-test and buster-test-cli module's, without much luck.

Another approach would be to call buster.spec.expose() then add a bit of magic to the expect() function, to allow the use of Jasmine matchers, and report the result back to the Buster environment.

Any thoughts/ideas greatly appreciated!

Cheers,
Matt.

August Lilleaas

unread,
Aug 13, 2012, 7:10:43 PM8/13/12
to Matt Fysh, buster...@googlegroups.com
Just a quick reply before I'm falling asleep on my desk,

I agree that a buster-jasmine adapter makes sense. Our bdd/spec APIs aim to be similar but not identical to jasmine. And a contribution here is definitely welcome in our cozy little meritocracy!

Take a look at buster-jstestdriver, the general idea is that you write functions that have the sane names as the jasmine ones, use that to collect data, and pass that data to buster. IIRC this is exactly what buster-jstestdriver does.

Sorrt for the relatively content-free reply, I just thought I'd show my appreciation :)

Matt Fysh

unread,
Aug 13, 2012, 7:19:13 PM8/13/12
to buster...@googlegroups.com, Matt Fysh
Thanks August!

Placeholder for the module is at  https://github.com/mattfysh/buster-jasmine 

Cheers,
Matt.

Christian Johansen

unread,
Aug 14, 2012, 2:58:03 AM8/14/12
to Matt Fysh, buster...@googlegroups.com
On Tue, Aug 14, 2012 at 12:51 AM, Matt Fysh <matt...@gmail.com> wrote:
I recently began to move all my projects over to BusterJS, but hit a few roadblocks with using buster's spec model.
For example, a toBeUndefined matcher does not exist, and I can't seem to find a simple way to test for not just an error, but the error message itself.

A quick note on that last thing: The error expectation/assertion is reworked for the next version. Don't think it's Jasmine compatible, but thought it was worth mentioning :)
 
I thought of modifying all my test cases but then realised the benefit of a buster-jasmine adapter (in the manner of jasmine's jsTestDriver adapter). There are many advantages to this:

1. Quickly and easily allow specs to run on BusterJS
2. Maintain a familiar BDD syntax
3. Access to Jasmine plugins
4. Add Jasmine users to the BusterJS community, always a bonus!

I agree that this is a good idea. Just so we're on the same page: The idea is to be able to run Jasmine tests with Buster, right?
 
I've got the Jasmine side of the adapter figured out - this is a matter of creating a new JsApiReporter and adding it to the runner, then listening for spec, suite and runner results.

I don't know much about how Jasmine works. Could you possibly provide a little more detail on how you envision this working?
 
Now I can't seem to find a way to get these results into Buster. Would anyone here have any idea where I should begin looking? I'm currently snooping around the buster-test and buster-test-cli module's, without much luck.

I actually have a couple of tutorials on integrating test frameworks lying around. I should really finish those up.
 
Another approach would be to call buster.spec.expose() then add a bit of magic to the expect() function, to allow the use of Jasmine matchers, and report the result back to the Buster environment.

Maybe a good place to start would be to note all the things that are different/not supported in Buster from Jasmine? The amount of differences will determine the best approach.

Thanks for doing this, really appreciated!

Christian

Matt Fysh

unread,
Aug 14, 2012, 9:16:55 PM8/14/12
to buster...@googlegroups.com, Matt Fysh, chri...@cjohansen.no
Smashed it! :)

I'll upload it to github tonight once I've tidied up the extension and then add it to npm.
Hopefully this helps those who use Jasmine to adopt Buster.

Matt.

August Lilleaas

unread,
Aug 15, 2012, 2:43:51 AM8/15/12
to Matt Fysh, buster...@googlegroups.com, chri...@cjohansen.no
Jolly good!

If you want to, we can make a repo for you on github.com/busterjs, making it an core project part of the core issue tracker, etc.. That's entirely up to you, of course. We plan to have an easy to find page on busterjs.org for findability, etc.

Matt Fysh

unread,
Aug 19, 2012, 9:16:32 AM8/19/12
to buster...@googlegroups.com, Matt Fysh, chri...@cjohansen.no
I ended up writing this as a simple test helper, as writing an extension didn't make much sense and seemed like a bit of overkill.

You can see the project here: https://github.com/mattfysh/jasmine-buster

Some things I realised while working with buster:

1. If multiple assertions fail in a spec, only the first is reported
2. buster.stackFilter is not available in the browser, however the documentation says it is
3. I have no idea how to use node

Cheers!
Matt.

Christian Johansen

unread,
Aug 20, 2012, 4:58:05 AM8/20/12
to Matt Fysh, buster...@googlegroups.com
Hi Matt,

Looks good! Eventually I'd like to help you wrap it up as an extension, as it will make using it even simpler. I also think we should allow `stackFilters: ["additional", "paths"]`  as part of the configuration.

It says that deferred tests are not reported. Buster supports them, so I was curious to what the reason for this is?

Comments to your, well, comments:
1. Yup, that's intended. I might be convinced to make this optional, but probably not :)
2. Adding additional paths to the configuration file solves that problem. Anyway, the stack is filtered server-side, not in the browser
3. :)

Christian

Matt Fysh

unread,
Aug 20, 2012, 9:15:11 AM8/20/12
to buster...@googlegroups.com, Matt Fysh, chri...@cjohansen.no
Hey Christian,

Deferred tests are not exposed by Jasmine so I can't report them. I have forked the Jasmine repo tho and if I get a chance on the weekend, I'll try to expose the deferreds so that they can be  reported to Buster. I'm also thinking of trying to get the time in ms that each test takes... it would be good to find out which tests are taking the longest.

I'm happy to convert the library to a buster extension, may have a go at that this week and get your feedback if that's ok?

Cheers,
Matt.

Christian Johansen

unread,
Aug 21, 2012, 3:38:15 AM8/21/12
to Matt Fysh, buster...@googlegroups.com

Sure, that sounds good!

Reply all
Reply to author
Forward
0 new messages