Expected assertion count

[Juan Mendes]

I just found https://github.com/jasmine/jasmine/issues/626 after a bug bit me on one of my tests. The issue was closed but I'm asking that it be reconsidered. 

The gist of it is that for asynchronous tests, it can be useful to tell a test how many assertions it expects in case some of your callbacks don't get called.

Here's an extremly simplified example: the test below should fail but ends up passing because I forgot to define the done parameter. A similar case just bit me on a project, so I googled for the expected assertion count feature and found that feature request which has been closed and infews said to ask here if I felt strongly that this feature should be added.

it('should check my variable after a timeout', function() { var val = true; setTimeout(function(){ expect(val).toBe(false); done(); }, 0); });

For the example above, you'll get an error somewhere in your log that done is not defined, which is helpful and should help you (still doesn't tell you that the test failed in your test results though). However, in my case, the callback was never being called because my widget under was being destroyed in the afterEach(), therefore, all the event handlers associated with it were never called.

Thanks,

[Pat Kujawa]

Some libraries make it an error if there are no assertions within a test, which would resolve these types of bugs. However, sometimes that's annoying and ends up with you asserting that true is true. Possibly a small price to pay.

If you are disciplined, following TDD best practices and ensuring that your tests first **fail** before they pass would also avoid these types of bugs, at least when the test is first written.

[Juan Mendes]

I do agree that making sure the test fails first is helpful, but that only helps when you first write a test. Somebody could change some code in the future that causes my callback not to be called anymore and the test would still pass, rendering my test pointless. 

Requiring at least a single assertion is better, but as much as I try to keep a single assertion per test, we always end up with a few tests that require more than a single assertion.

Regards,

On Friday, January 9, 2015 at 7:54:32 AM UTC-8, Pat Kujawa wrote:

Some libraries make it an error if there are no assertions within a test, which would resolve these types of bugs. However, sometimes that's annoying and ends up with you asserting that true is true. Possibly a small price to pay.

If you are disciplined, following TDD best practices and ensuring that your tests first **fail** before they pass would also avoid these types of bugs, at least when the test is first written.

On Thursday, January 8, 2015 at 1:09:45 PM UTC-7, Juan Mendes wrote:

I just found https://github.com/jasmine/jasmine/issues/626 after a bug bit me on one of my tests. The issue was closed but I'm asking that it be reconsidered. failt

[Gregg Van Hove]

Jasmine reports specs without expectations as a warning. The HtmlReporter will report them to `console.log` and add a message before the spec name in the html report as well. We don't want to make them spec failures as there are some use cases where users want a valid spec without any calls to `expect`.

-Gregg

--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jasmine-js+...@googlegroups.com.
To post to this group, send email to jasmi...@googlegroups.com.
Visit this group at http://groups.google.com/group/jasmine-js.
For more options, visit https://groups.google.com/d/optout.