[stiff]

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.

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.

[themckman]

The biggest thing from RSpec I've missed since switching from Ruby are the describe/it blocks. I felt like they helped you, as you were writing tests, compose sentences that, in the end, should be true about the system under test. It allowed you to abstract your thinking to a level that was more conducive to understanding the essence of the code/system. I'll agree with you on all the should/be stuff; TestUnit assertions work just fine.

[abe33]

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).

[tlrobinson]

"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"

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.

[zeckalpha]

It is these problems that make me think the QuickCheck family of testing frameworks will be a better approach in the long run.

One for JS: http://www.yellosoft.us/quickcheck