feedback after using buster.js
186 views
Skip to first unread message
Martijn Faassen
Aug 6, 2012, 8:43:15 AM8/6/12
to buster...@googlegroups.com
Hi there,
I've been using buster.js to convert some tests of Obviel
(http://obviel.org) from qunit. Overall it's a big improvement, so
thank you!
I figured I'd give a bit of feedback. Some of this feedback may be a
FAQ, but since I intend to start a buster.js FAQ just let me know and
I'll add it. :)
What is the procedure for adding docs? I find a buster-docs repo and
your development page has instructions on how to run a doc server, but
I also find a buster-docs-sphinx. I'm sort of hoping the latter is in
active use now, because I'm familiar with sphinx.
I had a weird out of memory error on IE 8 as a slave in a virtual
machine. It happens even if I just run a single test. Has anyone else
experienced this? How can I help debug this? I'd create an issue but
my report is rather unhelpful at this stage.
buster exception reporting seems a bit peculiar so I'm curious as to
motivations behind it. I had quite a few problems debugging existing
exceptions initially, as my exceptions didn't conform to what
buster.js wanted. buster.js would only report an 'undefined'
exception which was unhelpful in debugging. With qunit, I was used to
providing a toString() method for my exception that would help display
it, but buster.js seems to completely ignore that. In the end I
resorted to complying with what buster.js seems to want: a 'name'
property and a 'message' property. I'd be nice if buster.js could be
more jhelpful and generic in this area. I could study qunit (which
seemed more friendly) to see what is done there in case this is
helpful.
The way test names are outputted by buster test is hard to read. I see:
Firefox 14.0.1, Linux sync tests update to object URL
I cannot readily parse out the bits I want to know, i.e. the test case
name and the test name. Why not something like this?
Firefox 14.0.1, Linux | sync tests | update to object URL
Some of the coloration of the output is also hard to read on my
screen. I use a pretty common terminal setting: black text on a white
background. But part of the output is in a rather light yellow, that
is pretty hard to read on the white background. It'd be helpful if the
colors could be tweaked.
What is the pattern for defining helper functions in test cases?
Perhaps this is more a sinon.js question, but it interacts with
buster.js. I used a fake HTTP server using sinon.js. I wanted a helper
function that would let me define JSON URLs more easily. I initially
just added a helper method to the testCase, but that didn't work as it
of course it tried to run it as a test case. I ended up assigning the
helper function within 'setUp', along these lines:
setUp: function() {
this.helper = function() {
}
}
but i'd prefer to be able to take that outside of setUp. Is there some
better way to do this? In the end I'd like to share this helper
function between test cases as well. Would I create a special kind of
test case, or a special kind of fakeServer? Some guidance on patterns
here would be useful. I think there are different patterns too; here I
wanted to add some functionality that could actually go into sinon.js
as it's quite generic (sending back JSON in a more convenient way),
but in some other cases I really would like to define specific helpers
for particular test cases.
FAQs that I found the answers to and that I'll try to spell out:
* how to use firebug debugging with buster tests?
Answer:
$ buster test -p
will run the buster tests without changing the paths of the JavaScript
files loaded into the browser. Go to the browser capture screen in
Firefox. Enable Firebug and script debugging. Now run the tests once
with 'buster test p'. The appropriate paths will now be loaded in the
script debugging panel of Firebug. You can now set breakpoints which
will be triggered once you run the tests again.
When debugging it's useful to be able to run a test in isolation; you
can do this by including the test name (or part of it that uniquely
identifies it) after 'buster test -p', for instance:
$ buster test -p 'amazing test'
(note that buster static offers hope to be able to do this too, but
there's no way to isolate a test like you could do in qunit by
clicking on it, which is quite essential for in-browser debugging)
Unwritten FAQs (that I've answered enough to get going):
* how do I include test resources and then refer to them?
Answer should involve how to make a URL to them (which is a bit odd
concerning the way directories are handled, I'll get back to that),
and how you could use sinonjs instead. There's also an inconsistency
in the docs, the configuration doc says "To request a resource.. you
need to scope resource paths with buster.env.contextPath" though the
resource doc says you can simply refer to a resource if you expose it.
* how to set an alternative body per test.
There are some limitations to this; script elements in my custom body
didn't seem to be included.
Regards,
Martijn
I've been using buster.js to convert some tests of Obviel
(http://obviel.org) from qunit. Overall it's a big improvement, so
thank you!
I figured I'd give a bit of feedback. Some of this feedback may be a
FAQ, but since I intend to start a buster.js FAQ just let me know and
I'll add it. :)
What is the procedure for adding docs? I find a buster-docs repo and
your development page has instructions on how to run a doc server, but
I also find a buster-docs-sphinx. I'm sort of hoping the latter is in
active use now, because I'm familiar with sphinx.
I had a weird out of memory error on IE 8 as a slave in a virtual
machine. It happens even if I just run a single test. Has anyone else
experienced this? How can I help debug this? I'd create an issue but
my report is rather unhelpful at this stage.
buster exception reporting seems a bit peculiar so I'm curious as to
motivations behind it. I had quite a few problems debugging existing
exceptions initially, as my exceptions didn't conform to what
buster.js wanted. buster.js would only report an 'undefined'
exception which was unhelpful in debugging. With qunit, I was used to
providing a toString() method for my exception that would help display
it, but buster.js seems to completely ignore that. In the end I
resorted to complying with what buster.js seems to want: a 'name'
property and a 'message' property. I'd be nice if buster.js could be
more jhelpful and generic in this area. I could study qunit (which
seemed more friendly) to see what is done there in case this is
helpful.
The way test names are outputted by buster test is hard to read. I see:
Firefox 14.0.1, Linux sync tests update to object URL
I cannot readily parse out the bits I want to know, i.e. the test case
name and the test name. Why not something like this?
Firefox 14.0.1, Linux | sync tests | update to object URL
Some of the coloration of the output is also hard to read on my
screen. I use a pretty common terminal setting: black text on a white
background. But part of the output is in a rather light yellow, that
is pretty hard to read on the white background. It'd be helpful if the
colors could be tweaked.
What is the pattern for defining helper functions in test cases?
Perhaps this is more a sinon.js question, but it interacts with
buster.js. I used a fake HTTP server using sinon.js. I wanted a helper
function that would let me define JSON URLs more easily. I initially
just added a helper method to the testCase, but that didn't work as it
of course it tried to run it as a test case. I ended up assigning the
helper function within 'setUp', along these lines:
setUp: function() {
this.helper = function() {
}
}
but i'd prefer to be able to take that outside of setUp. Is there some
better way to do this? In the end I'd like to share this helper
function between test cases as well. Would I create a special kind of
test case, or a special kind of fakeServer? Some guidance on patterns
here would be useful. I think there are different patterns too; here I
wanted to add some functionality that could actually go into sinon.js
as it's quite generic (sending back JSON in a more convenient way),
but in some other cases I really would like to define specific helpers
for particular test cases.
FAQs that I found the answers to and that I'll try to spell out:
* how to use firebug debugging with buster tests?
Answer:
$ buster test -p
will run the buster tests without changing the paths of the JavaScript
files loaded into the browser. Go to the browser capture screen in
Firefox. Enable Firebug and script debugging. Now run the tests once
with 'buster test p'. The appropriate paths will now be loaded in the
script debugging panel of Firebug. You can now set breakpoints which
will be triggered once you run the tests again.
When debugging it's useful to be able to run a test in isolation; you
can do this by including the test name (or part of it that uniquely
identifies it) after 'buster test -p', for instance:
$ buster test -p 'amazing test'
(note that buster static offers hope to be able to do this too, but
there's no way to isolate a test like you could do in qunit by
clicking on it, which is quite essential for in-browser debugging)
Unwritten FAQs (that I've answered enough to get going):
* how do I include test resources and then refer to them?
Answer should involve how to make a URL to them (which is a bit odd
concerning the way directories are handled, I'll get back to that),
and how you could use sinonjs instead. There's also an inconsistency
in the docs, the configuration doc says "To request a resource.. you
need to scope resource paths with buster.env.contextPath" though the
resource doc says you can simply refer to a resource if you expose it.
* how to set an alternative body per test.
There are some limitations to this; script elements in my custom body
didn't seem to be included.
Regards,
Martijn
August Lilleaas
Aug 6, 2012, 9:27:37 AM8/6/12
to Martijn Faassen, buster...@googlegroups.com
Thanks! Just a general FYI, we haven't focused on polish the last months, as we're still adding features and fixing bugs to get ready for 1.0. So that's why a lot of stuff is undocumented etc.
buster-docs-sphinx is what we'll use for the docs in 1.0. buster-docs is the old one, but it's actually the one in use on busterjs.org right now, as we still need to add some more features to it before we switch. Namely API docs.
Got steps to reproduce?
This sounds like a worthy issue to me, feel free to post it to https://github.com/busterjs/buster/issues
The idea is that you construct your contexts to make a sentence. I think it probably makes sense to separate the browser name from this, though. Currently, browser names are kind of hacked in, by adding an outer context. There are plans to add this as an actual feature, so that the reporter is able to separate the browser name (or specifically, the test environment) from the test name.
Personally I agree that the context names should be separated too, because I don't usually write my contexts in sentence form. But I didn't write that code so that's not how it works :) Meritocracy ftw. Perhaps that is also a discussion for an issue in the issue tracker.
We've decided that this is up to you, so we don't provide any special feature for test helpers. In the end, a test helper is just a function, so it adds more obscurity than it does clarity.
One way would be to add a tests/test-helper.js and include it in the "tests" (or "specs") part of the config file. In it, you can define a bunch of global functions that you can use as test helpers. Or put them all in a namespace if you want to.
We should certainly have an FAQ as part of our docs, and I think all of the points you list here should be included. Good stuff!
On Mon, Aug 6, 2012 at 2:43 PM, Martijn Faassen <faa...@startifact.com> wrote:
Hi there,
I've been using buster.js to convert some tests of Obviel
(http://obviel.org) from qunit. Overall it's a big improvement, so
thank you!
I figured I'd give a bit of feedback. Some of this feedback may be a
FAQ, but since I intend to start a buster.js FAQ just let me know and
I'll add it. :)
What is the procedure for adding docs? I find a buster-docs repo and
your development page has instructions on how to run a doc server, but
I also find a buster-docs-sphinx. I'm sort of hoping the latter is in
active use now, because I'm familiar with sphinx.
buster-docs-sphinx is what we'll use for the docs in 1.0. buster-docs is the old one, but it's actually the one in use on busterjs.org right now, as we still need to add some more features to it before we switch. Namely API docs.
I had a weird out of memory error on IE 8 as a slave in a virtual
machine. It happens even if I just run a single test. Has anyone else
experienced this? How can I help debug this? I'd create an issue but
my report is rather unhelpful at this stage.
Got steps to reproduce?
buster exception reporting seems a bit peculiar so I'm curious as to
motivations behind it. I had quite a few problems debugging existing
exceptions initially, as my exceptions didn't conform to what
buster.js wanted. buster.js would only report an 'undefined'
exception which was unhelpful in debugging. With qunit, I was used to
providing a toString() method for my exception that would help display
it, but buster.js seems to completely ignore that. In the end I
resorted to complying with what buster.js seems to want: a 'name'
property and a 'message' property. I'd be nice if buster.js could be
more jhelpful and generic in this area. I could study qunit (which
seemed more friendly) to see what is done there in case this is
helpful.
This sounds like a worthy issue to me, feel free to post it to https://github.com/busterjs/buster/issues
The way test names are outputted by buster test is hard to read. I see:
Firefox 14.0.1, Linux sync tests update to object URL
I cannot readily parse out the bits I want to know, i.e. the test case
name and the test name. Why not something like this?
Firefox 14.0.1, Linux | sync tests | update to object URL
Some of the coloration of the output is also hard to read on my
screen. I use a pretty common terminal setting: black text on a white
background. But part of the output is in a rather light yellow, that
is pretty hard to read on the white background. It'd be helpful if the
colors could be tweaked.
The idea is that you construct your contexts to make a sentence. I think it probably makes sense to separate the browser name from this, though. Currently, browser names are kind of hacked in, by adding an outer context. There are plans to add this as an actual feature, so that the reporter is able to separate the browser name (or specifically, the test environment) from the test name.
Personally I agree that the context names should be separated too, because I don't usually write my contexts in sentence form. But I didn't write that code so that's not how it works :) Meritocracy ftw. Perhaps that is also a discussion for an issue in the issue tracker.
What is the pattern for defining helper functions in test cases?
Perhaps this is more a sinon.js question, but it interacts with
buster.js. I used a fake HTTP server using sinon.js. I wanted a helper
function that would let me define JSON URLs more easily. I initially
just added a helper method to the testCase, but that didn't work as it
of course it tried to run it as a test case. I ended up assigning the
helper function within 'setUp', along these lines:
setUp: function() {
this.helper = function() {
}
}
but i'd prefer to be able to take that outside of setUp. Is there some
better way to do this? In the end I'd like to share this helper
function between test cases as well. Would I create a special kind of
test case, or a special kind of fakeServer? Some guidance on patterns
here would be useful. I think there are different patterns too; here I
wanted to add some functionality that could actually go into sinon.js
as it's quite generic (sending back JSON in a more convenient way),
but in some other cases I really would like to define specific helpers
for particular test cases.
We've decided that this is up to you, so we don't provide any special feature for test helpers. In the end, a test helper is just a function, so it adds more obscurity than it does clarity.
One way would be to add a tests/test-helper.js and include it in the "tests" (or "specs") part of the config file. In it, you can define a bunch of global functions that you can use as test helpers. Or put them all in a namespace if you want to.
We should certainly have an FAQ as part of our docs, and I think all of the points you list here should be included. Good stuff!
Regards,
Martijn
Martijn Faassen
Aug 6, 2012, 9:48:01 AM8/6/12
to buster...@googlegroups.com
Hey,
Just so I don't forget myself:
Regards,
Martijn
Just so I don't forget myself:
> * how to use firebug debugging with buster tests?
>
> Answer:
>
> $ buster test -p
>
> will run the buster tests without changing the paths of the JavaScript
> files loaded into the browser. Go to the browser capture screen in
> Firefox. Enable Firebug and script debugging.
And you need to recapture the browser after doing that.
>
> Answer:
>
> $ buster test -p
>
> will run the buster tests without changing the paths of the JavaScript
> files loaded into the browser. Go to the browser capture screen in
> Firefox. Enable Firebug and script debugging.
Regards,
Martijn
Christian Johansen
Aug 6, 2012, 9:58:36 AM8/6/12
to Buster.JS development
First of all, thanks for the thorough feedback, Martijn! This sort of stuff is invaluable as we're trying to tighten all the loose strings and get to a friendly polished 1.0. See comments below.
Agree. We could easily improve this by trying more properties before logging. We could even fall back to buster.format.ascii(err) when all else fails, that would at least show you all the properties.
...
There is a very simple solution to this: Write a new reporter. Also, like August says, the next "major" version of Buster (the first RC according to our plans) will know that parts of that string is the environment, and not just a context.
Over my vacation, I've been writing some guides on customizing parts of Buster. It includes an example-driven tutorial on making a reporter. I will post these soon-ish.
I think we need to recognize the fact that the helpers often need to work on the "this" object if it wants to do spying, fake servers, tweak timeouts and other things. I guess it makes sense to either provide an object that can be embellished, or provide an API to add helpers, e.g.:
buster.testCase.addHelper("bleh", function (all) {
this.stub(all, "theThings");
});
--
MVH
Christian
buster exception reporting seems a bit peculiar so I'm curious as to
motivations behind it. I had quite a few problems debugging existing
exceptions initially, as my exceptions didn't conform to what
buster.js wanted. buster.js would only report an 'undefined'
exception which was unhelpful in debugging. With qunit, I was used to
providing a toString() method for my exception that would help display
it, but buster.js seems to completely ignore that. In the end I
resorted to complying with what buster.js seems to want: a 'name'
property and a 'message' property. I'd be nice if buster.js could be
more jhelpful and generic in this area. I could study qunit (which
seemed more friendly) to see what is done there in case this is
helpful.
This sounds like a worthy issue to me, feel free to post it to https://github.com/busterjs/buster/issues
Agree. We could easily improve this by trying more properties before logging. We could even fall back to buster.format.ascii(err) when all else fails, that would at least show you all the properties.
The way test names are outputted by buster test is hard to read. I see:
Firefox 14.0.1, Linux sync tests update to object URL
...
Personally I agree that the context names should be separated too, because I don't usually write my contexts in sentence form. But I didn't write that code so that's not how it works :) Meritocracy ftw. Perhaps that is also a discussion for an issue in the issue tracker.
There is a very simple solution to this: Write a new reporter. Also, like August says, the next "major" version of Buster (the first RC according to our plans) will know that parts of that string is the environment, and not just a context.
Over my vacation, I've been writing some guides on customizing parts of Buster. It includes an example-driven tutorial on making a reporter. I will post these soon-ish.
but i'd prefer to be able to take that outside of setUp. Is there some
better way to do this? In the end I'd like to share this helper
function between test cases as well. Would I create a special kind of
test case, or a special kind of fakeServer? Some guidance on patterns
here would be useful. I think there are different patterns too; here I
wanted to add some functionality that could actually go into sinon.js
as it's quite generic (sending back JSON in a more convenient way),
but in some other cases I really would like to define specific helpers
for particular test cases.
We've decided that this is up to you, so we don't provide any special feature for test helpers. In the end, a test helper is just a function, so it adds more obscurity than it does clarity.
I think we need to recognize the fact that the helpers often need to work on the "this" object if it wants to do spying, fake servers, tweak timeouts and other things. I guess it makes sense to either provide an object that can be embellished, or provide an API to add helpers, e.g.:
buster.testCase.addHelper("bleh", function (all) {
this.stub(all, "theThings");
});
--
MVH
Christian
Martijn Faassen
Aug 6, 2012, 10:04:27 AM8/6/12
to August Lilleaas, buster...@googlegroups.com
Hi there,
Thanks for the quick feedback to my feedback!
On Mon, Aug 6, 2012 at 3:27 PM, August Lilleaas <aug...@augustl.com> wrote:
>> I had a weird out of memory error on IE 8 as a slave in a virtual
>> machine. It happens even if I just run a single test. Has anyone else
>> experienced this? How can I help debug this? I'd create an issue but
>> my report is rather unhelpful at this stage.
>
> Got steps to reproduce?
Yes, in my case it seems to happen for a single test case on my
virtual machine, but I understand that this can't be reproduced
everywhere. I'll fiddle around with it some more. I hope someone else
ran into this and will speak up.
> This sounds like a worthy issue to me, feel free to post it to
> https://github.com/busterjs/buster/issues
Done:
https://github.com/busterjs/buster/issues/253
Another exception related detail I missed from buster.js that I'm used
to with qunit is being able to catch an exception by instance, i.e. in
qunit I can do the equivalent of:
var MyException = function() {
};
assert.exception(function() {
throw new MyException();
}, MyException);
In buster.js I only can work with strings.
> The idea is that you construct your contexts to make a sentence.
from other testing systems, so I think this needs a bit more
explanation.
Can you use this sentence including test case name to identify a test
in a particular test case?
I guess I could simply include a colon at the end of my test case name...
Created an issue:
https://github.com/busterjs/buster/issues/254
> We've decided that this is up to you, so we don't provide any special
> feature for test helpers.
It was not helpful that the intuitive pattern for me to use is to add
this functionality to the test case; I'm used to test runners where I
can do this because actual tests have to start with the prefix 'test'
(Python unit test and pytest for instance). Then I tripped over the
way test cases are picked up in buster.js.. So some guidance in docs
on patterns this would be nice. I think there multiple use cases:
* an application specific test framework shared by many tests; make a
separate module andi nclude it as you suggest
* testcase specific helpers; either global functions (though will they
be really global? that's a bit dangerous) or defining the function in
'setUp'
* extensions to sinonjs behavior, i.e. adding a convenience to create
server urls that return JSON. Subclassing? Something else?
> We should certainly have an FAQ as part of our docs, and I think all of the
> points you list here should be included. Good stuff!
Where to start one? Sphinx docs, classic documentation or both?
Regards,
Martijn
Thanks for the quick feedback to my feedback!
On Mon, Aug 6, 2012 at 3:27 PM, August Lilleaas <aug...@augustl.com> wrote:
>> I had a weird out of memory error on IE 8 as a slave in a virtual
>> machine. It happens even if I just run a single test. Has anyone else
>> experienced this? How can I help debug this? I'd create an issue but
>> my report is rather unhelpful at this stage.
>
> Got steps to reproduce?
virtual machine, but I understand that this can't be reproduced
everywhere. I'll fiddle around with it some more. I hope someone else
ran into this and will speak up.
> This sounds like a worthy issue to me, feel free to post it to
> https://github.com/busterjs/buster/issues
https://github.com/busterjs/buster/issues/253
Another exception related detail I missed from buster.js that I'm used
to with qunit is being able to catch an exception by instance, i.e. in
qunit I can do the equivalent of:
var MyException = function() {
};
assert.exception(function() {
throw new MyException();
}, MyException);
In buster.js I only can work with strings.
> The idea is that you construct your contexts to make a sentence.
> Personally I agree that the context names should be separated too, because I
> don't usually write my contexts in sentence form. But I didn't write that
> code so that's not how it works :) Meritocracy ftw. Perhaps that is also a
> discussion for an issue in the issue tracker.
Could you (or someone) give an example? I'm not used to this approach
> don't usually write my contexts in sentence form. But I didn't write that
> code so that's not how it works :) Meritocracy ftw. Perhaps that is also a
> discussion for an issue in the issue tracker.
from other testing systems, so I think this needs a bit more
explanation.
Can you use this sentence including test case name to identify a test
in a particular test case?
I guess I could simply include a colon at the end of my test case name...
Created an issue:
https://github.com/busterjs/buster/issues/254
> We've decided that this is up to you, so we don't provide any special
> feature for test helpers.
this functionality to the test case; I'm used to test runners where I
can do this because actual tests have to start with the prefix 'test'
(Python unit test and pytest for instance). Then I tripped over the
way test cases are picked up in buster.js.. So some guidance in docs
on patterns this would be nice. I think there multiple use cases:
* an application specific test framework shared by many tests; make a
separate module andi nclude it as you suggest
* testcase specific helpers; either global functions (though will they
be really global? that's a bit dangerous) or defining the function in
'setUp'
* extensions to sinonjs behavior, i.e. adding a convenience to create
server urls that return JSON. Subclassing? Something else?
> We should certainly have an FAQ as part of our docs, and I think all of the
> points you list here should be included. Good stuff!
Regards,
Martijn
Martijn Faassen
Aug 6, 2012, 10:11:13 AM8/6/12
to Christian Johansen, Buster.JS development
Hi there,
On Mon, Aug 6, 2012 at 3:58 PM, Christian Johansen
<chri...@cjohansen.no> wrote:
>> Personally I agree that the context names should be separated too, because
>> I don't usually write my contexts in sentence form. But I didn't write that
>> code so that's not how it works :) Meritocracy ftw. Perhaps that is also a
>> discussion for an issue in the issue tracker.
>
> There is a very simple solution to this: Write a new reporter. Also, like
> August says, the next "major" version of Buster (the first RC according to
> our plans) will know that parts of that string is the environment, and not
> just a context.
> Over my vacation, I've been writing some guides on customizing parts of
> Buster. It includes an example-driven tutorial on making a reporter. I will
> post these soon-ish.
While pluggability is invaluable, another question is what should be
the default behavior. It seems to me buster.js is doing a bit of
advocacy here on how people are supposed to name their tests, as this
is at least unfamiliar to me:
https://github.com/busterjs/buster/issues/254
> I think we need to recognize the fact that the helpers often need to work on
> the "this" object if it wants to do spying, fake servers, tweak timeouts and
> other things. I guess it makes sense to either provide an object that can be
> embellished, or provide an API to add helpers, e.g.:
>
> buster.testCase.addHelper("bleh", function (all) {
> this.stub(all, "theThings");
> });
Something like that would help!
buster.js is doing the inverse of what I'm used to. What I'm used to
is that methods prefixed with 'test' are special and will be test
cases. In buster.js instead treats methods like setUp, tearDown, etc,
as special and the rest as tests. By that reasoning you could come up
with a convention that those methods prefixed by 'helper' are also
special and therefore not tests.
Regards,
Martijn
On Mon, Aug 6, 2012 at 3:58 PM, Christian Johansen
<chri...@cjohansen.no> wrote:
>> Personally I agree that the context names should be separated too, because
>> I don't usually write my contexts in sentence form. But I didn't write that
>> code so that's not how it works :) Meritocracy ftw. Perhaps that is also a
>> discussion for an issue in the issue tracker.
>
> There is a very simple solution to this: Write a new reporter. Also, like
> August says, the next "major" version of Buster (the first RC according to
> our plans) will know that parts of that string is the environment, and not
> just a context.
> Over my vacation, I've been writing some guides on customizing parts of
> Buster. It includes an example-driven tutorial on making a reporter. I will
> post these soon-ish.
the default behavior. It seems to me buster.js is doing a bit of
advocacy here on how people are supposed to name their tests, as this
is at least unfamiliar to me:
https://github.com/busterjs/buster/issues/254
> I think we need to recognize the fact that the helpers often need to work on
> the "this" object if it wants to do spying, fake servers, tweak timeouts and
> other things. I guess it makes sense to either provide an object that can be
> embellished, or provide an API to add helpers, e.g.:
>
> buster.testCase.addHelper("bleh", function (all) {
> this.stub(all, "theThings");
> });
buster.js is doing the inverse of what I'm used to. What I'm used to
is that methods prefixed with 'test' are special and will be test
cases. In buster.js instead treats methods like setUp, tearDown, etc,
as special and the rest as tests. By that reasoning you could come up
with a convention that those methods prefixed by 'helper' are also
special and therefore not tests.
Regards,
Martijn
Christian Johansen
Aug 6, 2012, 10:27:15 AM8/6/12
to Martijn Faassen, Buster.JS development
While pluggability is invaluable, another question is what should be
the default behavior. It seems to me buster.js is doing a bit of
advocacy here on how people are supposed to name their tests, as this
is at least unfamiliar to me:
https://github.com/busterjs/buster/issues/254
The defaults should of course be influenced by what's generally most useful to most people, but I don't think it hurts Buster to have a little bit of a personality.
> I think we need to recognize the fact that the helpers often need to work on
> the "this" object if it wants to do spying, fake servers, tweak timeouts and
> other things. I guess it makes sense to either provide an object that can be
> embellished, or provide an API to add helpers, e.g.:
>
> buster.testCase.addHelper("bleh", function (all) {
> this.stub(all, "theThings");
> });
Something like that would help!
buster.js is doing the inverse of what I'm used to. What I'm used to
is that methods prefixed with 'test' are special and will be test
cases. In buster.js instead treats methods like setUp, tearDown, etc,
as special and the rest as tests. By that reasoning you could come up
with a convention that those methods prefixed by 'helper' are also
special and therefore not tests.
Yes, possibly, but I like the external approach better, as it's easier to stash away in helper files. I think it's better if the test cases don't contain helpers.
Christian
Richard Zurad
Aug 7, 2012, 12:37:26 PM8/7/12
to buster...@googlegroups.com, August Lilleaas
On Monday, August 6, 2012 7:04:27 AM UTC-7, Martijn Faassen wrote:
On Mon, Aug 6, 2012 at 3:27 PM, August Lilleaas <aug...@augustl.com> wrote:
>> I had a weird out of memory error on IE 8 as a slave in a virtual
>> machine. It happens even if I just run a single test. Has anyone else
>> experienced this? How can I help debug this? I'd create an issue but
>> my report is rather unhelpful at this stage.
>
> Got steps to reproduce?
Yes, in my case it seems to happen for a single test case on my
virtual machine, but I understand that this can't be reproduced
everywhere. I'll fiddle around with it some more. I hope someone else
ran into this and will speak up.
I got you covered :) https://github.com/busterjs/buster/issues/242
August Lilleaas
Aug 7, 2012, 1:35:09 PM8/7/12
to Richard Zurad, buster...@googlegroups.com
High quality stuff, man, thanks!
Martijn Faassen
Aug 7, 2012, 9:32:47 PM8/7/12
to Christian Johansen, Buster.JS development
Hi there,
On Mon, Aug 6, 2012 at 4:27 PM, Christian Johansen
<chri...@cjohansen.no> wrote:
> The defaults should of course be influenced by what's generally most useful
> to most people, but I don't think it hurts Buster to have a little bit of a
> personality.
Of course. Though documentation about this aspect of its personality
(if it be the default) would be useful as it surprised me and
I didn't consider it a feature; perhaps I missed the motivation in the docs?
> Yes, possibly, but I like the external approach better, as it's easier to
> stash away in helper files. I think it's better if the test cases don't
> contain helpers.
It depends on what the helper is doing, doesn't it? If it's a helper
very specific to the test case, then I prefer it to be near the test
case. If it's a more generic helper, it can go into a helper file.
Regards,
Martijn
On Mon, Aug 6, 2012 at 4:27 PM, Christian Johansen
<chri...@cjohansen.no> wrote:
> The defaults should of course be influenced by what's generally most useful
> to most people, but I don't think it hurts Buster to have a little bit of a
> personality.
(if it be the default) would be useful as it surprised me and
I didn't consider it a feature; perhaps I missed the motivation in the docs?
> Yes, possibly, but I like the external approach better, as it's easier to
> stash away in helper files. I think it's better if the test cases don't
> contain helpers.
very specific to the test case, then I prefer it to be near the test
case. If it's a more generic helper, it can go into a helper file.
Regards,
Martijn
Martijn Faassen
Aug 7, 2012, 9:33:55 PM8/7/12
to Richard Zurad, buster...@googlegroups.com, August Lilleaas
Hey,
[IE 8 out of memory]
Awesome, thanks!
Regards,
Martijn
[IE 8 out of memory]
Awesome, thanks!
Regards,
Martijn
Christian Johansen
Aug 8, 2012, 2:18:47 AM8/8/12
to Martijn Faassen, Buster.JS development
Of course. Though documentation about this aspect of its personality
(if it be the default) would be useful as it surprised me and
I didn't consider it a feature; perhaps I missed the motivation in the docs?
The docs are very rough at this point. They will receive due love this fall.
It depends on what the helper is doing, doesn't it? If it's a helper
very specific to the test case, then I prefer it to be near the test
case. If it's a more generic helper, it can go into a helper file.
Sure. With the API approach, you can choose where to put it - in the same file as the test case, or another.
Christian
Reply all
Reply to author
Forward
0 new messages