I was an early adopter of RSpec, have been using it for years now, and I came to think it's not worth it. More generally, mimicking natural language with a programming language DSL seems like a very bad idea. It seems nice that the tests look like a specification in english, but it is a one way correspondence, then you start to write things that look like they should work because they reassemble an english sentence but they don't really work because of the limitations of semantics of the programming language; moreover those can fail silently or work in ways other than expected. And this is so after the RSpec guys inserted all this rocket-science to make the DSL as elaborate as possible, in the process often introducing tricky bugs because the code for accomplishing this is so complex.<p>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.
So I get that I can do the following with Spectacular<p><pre><code> itsInstance 'length', -> should equal 0
</code></pre>
Instead of what I can currently do with Mocha+Chai.js<p><pre><code> item.length.should.equal 0
</code></pre>
But besides the different syntax (which doesn't matter to me) what does this framework offer me that Mocha+Chai.js doesn't?<p>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).
Does this provide any advantages over Jasmine for JavaScript BDD called by Karma (formerly Testacular) as the Test Runner?<p><a href="http://pivotal.github.io/jasmine/" rel="nofollow">http://pivotal.github.io/jasmine/</a><p><a href="http://karma-runner.github.io/0.8/index.html" rel="nofollow">http://karma-runner.github.io/0.8/index.html</a>
I like the async test handling better than Jasmine. It's the first thing I look for in testing frameworks nowadays.<p>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.<p>Moving to a promise-based system is definitely something I'm considering investigating.<p>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.
It does look interesting indeed.<p>I also like the design and layout of the site.<p>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]<p>edit: I'm referring to the download button here: <a href="http://abe33.github.io/spectacular/#Browser" rel="nofollow">http://abe33.github.io/spectacular/#Browser</a>
Seems like the author combined the spec side of mocha with should.js and a stub/mocking library, focused it on node and polished it up with some neat conventions and utilities.<p>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.
I'm really not a fan of having the options on window.options. Not only is that weirdly populating the window object with single use options. It also is extremely not targeted. At least it should be window.something.options.