I didn't followed that approach, matchers (like in RSpec) returns a boolean (or a promise of a boolean value). Errors raised in a matcher will be catched and, as in RSpec, will flag the test as errored (and not as failed).
I've always found it more useful to detect when something went wrong in your test setup than failures.
I can't completely agree with both of you regarding assertions.
There's always cases where a test needs to be done on several properties of an object at once (validation of a rails model attribute, for instance, when you want to test that the model is invalid and that the right error message is present) or where the setup to prepare the assertions is quite heavy, I think this is where custom assertions can be quite helpful, first it gives you more meaningful tests, and the reported failures can be more documented than with asserts.
In that regard, you can write simpler assertions for each of these tests, and do that for every fields of every models. In the end it's a lot of code duplication that may also lead to errors (tests have to be refactored as much as the tested code).
I must say that I'm also a user and lover of jasmine, all the previous lib I did was tested using Jasmine. However, I was missing some feature from RSpec (Jasmine, like Mocha, takes a big part of their syntax from RSpec), such implicit subjects, let blocks, self-describing matchers, etc.
If I were to list some of the advantages of Spectacular over Jasmine, I'll say there is:
- native nodejs support: Jasmine was primarily intended for browsers, and the jasmine-node module isn't guaranteed to use the latest jasmine version.
- subject, auto-subject describe and implicit subject in test. This is quite handy and when combined with CoffeeScript syntax it leads to very readable tests
- first class async support: asynchronous tests aren't just an edge case, but are at the root of the framework. Even matchers can be asynchronous, allowing to write matchers such as the shoulda's have_db_column matcher, that, in a javascript context, will have to rely on asynchronous API.
- built-in factories in FactoryGirl fashion.
- tests randomization
- tests dependencies
- out-of-the-box phantomjs and slimerjs support
As a last word I want to say that, at the beginning of this project, the idea was to see how I could build a BDD/TDD framework using BDD/TDD, and, as a RSpec user, I wanted to have the same kind of feeling that I can have when I write RSpec tests: simplicity, readability, reusability, etc. In the end it grew as something that could benefit others and so I pushed the development further in order to provides a full and robust framework.