Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

I don't like the dsl. While admittedly it is entirely a question of preference, I find it more natural to write some ruby code and then assert(something). As an example, from Hartl's tutorial we have a test dealing with microposts:

    subject { @micropost }
    it { should respond_to(:content) }
I prefer writing:

    assert @micropost.respond_to?(:content)
I haven't looked at rspec in a while and in the rspec example I don't remember how long the subject stays in scope nor would I remember to put braces between 'it' and 'should'. In the testunit example, it's all ruby, there isn't anything more I need to know.

It sounds strange, but even though the rspec example reads more like english, I find the assert more readable. Maybe it has something to do with the braces.

As a beginner, there are so many choices you have to make and so many things you have to learn. Rspec adds another item to that list. I would have preferred to learn to write tests with testunit and fixtures and then be presented with rspec, cucumber, factories, etc., a little later.

Have you used both rspec and testunit or just the former?



That rspec example looks like some sort of misguided language skeuomorphism. "If I name this method 'it' and this one 'should' and this one 'subject', I get something that sort of looks like English if you read it out loud while skipping the symbols! Isn't that neat?"

Well, no, it's a horrible idea, because in English those words would imply a certain syntax tree, while the actual syntax tree in your DSL is completely different, and those words have completely different roles from the ones they have in English. So you have something that superficially looks like English if you take care to arrange it just right, but in fact works in a completely different way from how you know English to work.

It's like having a picture of a sliding knob in your application, except instead of sliding it you're supposed to click it, and it's actually used as a tab switcher. And you put a denim texture on it.


Thank you for explaining my immediate visceral discomfort on being introduced to rspec and cucumber more eloquently than I could.


It's worth noting that rspec gives you lots of options.

    @micropost.should respond_to(:content)
is perfectly valid, and IMO, much cleaner.


But that's the thing.

    rspec:    @micropost.should respond_to(:context)
    testunit: assert @micropost.respond_to?(:context)

    rspec:    @micropost.should be_valid
    testunit: assert @micropost.valid?

    rspec:    @micropost.should_not be_valid
    testunit: refute @micropost.valid?
The testunit It's Just Ruby examples end up looking like the syntactic sugar!


Fair. I can definitely appreciate the DSL argument. Rails has a rickety enough learning curve as it is, and introducing rspec at the outset is certainly debatable.

For what it's worth, I would definitely not consider the rspec syntax in that Hartl snippet to be a particularly legible example. The code provided in another comment is a much better representation of good style, IMHO.


rspec has some redeeming qualities that were luckily ported to minispec, especially the let-syntax. Once you grok how it works, its a very nice way to setup complex test data that has minor differences.

assert, in my opinion, has the distinct advantage of being immediately recognizable as a special thing while should reads kind of informal.


Wouldn't say `let` is so much better than `def setup` as a newcomer. `def setup` is simple and powerful enough and after a while you begin to wonder whether something like `let` exists.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: