New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async test "done" callbacks should take an optional error in Jasmine 2.0 #423
Comments
In this use case, where's the expectation to show the failure? |
If I understand your question, in my implementation, I put the expectation inside of callDone in Spec.js:
With this implementation, the example above would show "Expected function not to throw, but it threw 'save error'." in the test report. |
We're not fans of that idea. Expectations should be very explicitly inside your it - that's in the spirit of keeping your tests as better explicit documentation of how the code works. From a Jasmine implementation perspective, having Spec know about We want to encourage specs of the more wordy example. And yet, what are you really trying to test in that example? |
I see. Purely from an implementation perspective, to fix the abstraction rule violation, I could replace the
But from what I understand you saying, that's not the Jasmine way since the expectation isn't written out explicitly in test code. What we're trying to test is that our async code follows expected paths. We use jQuery promises heavily, so in each instance, we expect that .done() was called and .fail() was not (or vice-versa if we're doing negative case testing). Here's one way I could write out those expectations:
For a few tests, this is OK. But we have over 60 async tests like this currently, and writing more every day. So, we're looking for ways to make our async test code easy to read and write, and the first example I posted is one approach. Do you have any recommendations on how we should approach this problem? Thanks for your consideration. |
I don't know enough about your code or the particular promise implementation. But it seems that you're executing a lot of code in order to test the callback paths. I'd consider maybe only testing the success callback in a valid case and the failing case in the invalid save. Pairing those two tests together will make the suite easier to read and still give you sufficient coverage. I'm also a fan of not over DRYing specs. Yes, it may seem tedious. But remember that you're typing for the future you to understand the test suite, not just the you that is tired of typing today. Said from a different take, @ragaskar is always reminding me that a painful test suite is trying to tell you something - usually that your objects are factored wrong. Let's take this over to the Jasmine mailing list and have more people contribute tips. |
I really like that Jasmine 2.0 has adopted a Mocha-like done() callback for completing async tests - they're much easier to write now. Mocha's done() callback also accepts an optional error parameter; if omitted, the test succeeds, otherwise the test fails by throwing the error. I propose that Jasmine adds the same support to make it easier to write async tests.
An example of how to use this feature:
Without this support, async test failures are a little more cumbersome to write. In this example, I have to force a test failure in my callback function before calling done():
I modified Spec.js to support this in my local copy of Jasmine. I can submit a pull request you're interested.
The text was updated successfully, but these errors were encountered: