Since there are no tests for tests, tests should be written in really the simplest possible way. The principal goal of a test framework should be simplicity, reproducibility and reliability. In the end non-programmers anyway don't read the "specs" unless you are living in a fantasy world of the TDD gurus.
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).
This is why I can't stand AppleScript. It sort of looks like English prose, but you still have to figure out precisely what syntax is valid.
One for JS: http://www.yellosoft.us/quickcheck
itsInstance 'length', -> should equal 0
item.length.should.equal 0
Btw. the above is an honest genuine question. I'm not questioning that the framework has something to offer I just can't figure out what it is from reading the website (the DOM features doesn't mean anything to me since I'm currently writing tests for a library).
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.
I find Jasmine closer to mini test
I mostly use jasmine but they are both excellent frameworks.
I'm working on a simple lightweight framework at the moment that's designed to run on browsers in target environments such as VMs or cloud browsers, and a lot of my code deals with async issues.
Moving to a promise-based system is definitely something I'm considering investigating.
One pet peeve I have with all of these test frameworks though is the "kitchen sink" approach: there is always a substantial list of features. This led to me to roll my own.
I also like the design and layout of the site.
BUT: Does the "Download" button behave weird for anyone else as well? It's quite slow, not really responsive, and at the same time pushes the content below the button downwards/upwards depending on state (might be part of being slow). [Safari on OS X]
edit: I'm referring to the download button here: http://abe33.github.io/spectacular/#Browser
I'll probably give it a shot on my next project. I'm interested in finding out if it went the route of throwing exceptions for error reporting like mocha, or something else.