For example, in your spec, I would recommend that you don't test both
#add and #remove in the same example. That would save you from this
particular case.
-Corey
> --
> 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.
>
>
--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
expect(userlist.getUsers().length).toEqual(1).because('when a user
object is removed, the list should equal 1');
We never implemented it, but I don't see any reason why we couldn't
going forward -- it shouldn't really affect the utility of jasmine for
any other users.
Thanks!
Rajan
So, having a #remove(user) method would need an example like
describe("#remove", function() {
it("removes an added user from the list", function() {
// setup
userlist.add(user);
userlist.remove(user);
expect(userlist.contains(user)).toBe(false);
// or even better
expect(userlist).toNotContain(user);
});
});
This is the expected behavior. Reaching into the list and getting the
underlying data structure and asking for its length is worrisome from
a design perspective. If you really want to have a #length property on
the userlist object, then an example like
describe("#remove", function() {
it("decrements the count by one", function() {
var originalLength = userlist.length;
userlist.remove(user);
expect(userlist.length).toEqual(originalLength - 1);
});
});
If either of these fail, you get the necessary information to find
what was wrong. So, in the case of decrementing the length, the
failure is something like:
expected: 1
got: 2
Failure: #remove - decrements the count by one
That's a pretty clear message without the need to add further description text.
I have a general rule of thumb in these cases that I use in my own
coding practices: if I find myself without the information that I need
to rapidly trace the problem, assume there is a problem in the way I'm
writing my examples, rather than in the tools I'm using. Using this, I
often find myself guided towards a better understanding of how to
write good examples. It isn't always possible to write better
examples, and sometimes the tool itself has deficiencies, but I've
found my understanding of how to test effectively, as well as my
understanding of the underlying language constructs, has benefited
greatly from questioning myself first.
Wow, that sounded a bit like a rant. Sorry, I don't have time to make
it shorter. :)
-Corey
If you could provide a specific example of that pattern's usage. Is
this checking the parameters to a method (lots of times an abstraction
is somewhere causing the function to require too many options, or I'm
testing incidental/unnecessary things) or a return value from
something, in which case I most likely am doing too much in the
function, or I should be testing what is done with the values.
Now, I'm not saying that you'll never, ever find a need for this. This
pattern, though, frequently points to common design/expectation
smells, especially when written in a generic fashion like that.
-Corey
> For more options, visit this group at http://groups.google.com/group/jasmine-js?hl=en.
-Corey
> For more options, visit this group at http://groups.google.com/group/jasmine-js?hl=en.
When I get situations like that, I try to look to see whether I really
need to have those examples in that format. So, in this case, do you
really need to check that the positions are in pixels? Or, are you
really more interested in the relative position to something else,
perhaps its previous location or the mouse position?
In the case of checking #stick, does your code change the padding,
etc? Would it be enough to check that a class has been applied,
something like 'stuck' which contains those values?
-Corey
> For more options, visit this group at http://groups.google.com/group/jasmine-js?hl=en.
var context;
when("the context is set to 'first'", function(){
context = "first";
}).it("should be 'first'", function(){
expect(context).toEqual("first");
});
seems to be a shorthand for:
var context;
describe("the context is set to 'first'", function(){
beforeEach(function() {
context = "first";
})
it("should be 'first'", function(){
expect(context).toEqual("first");
});
});
I can see a shorthand like that being useful, though I don't know if
it would benefit much of my code. Normally I have a "var context;"
within the describe() block rather than before it.