Pragmatic Forums | Posts in topic 'RSpec API - The Good and the Bad'

RSpec API - The Good and the Bad posted by David Chelimsky @ Fri, 17 Sep 2010 00:08:05 +0000

David Chelimsky — Fri, 17 Sep 2010 00:09:33 +0000

re: subjectivity, we simply disagree. I believe that you are recommending good guidelines, but guidelines, in my view, are just guidelines and need to be considered in context. Same applies to “basics of good API design.” The things that you complain about (parametric coupling, let, subject, etc) are the very things that many who prefer RSpec over other alternatives cite when asked why.

re: bubble words, I get what you’re saying, but I wanted the have matcher to be consistent whether specifying an object that owns a collection or an object that is a collection. As things stand you can say team.should have(5).players and players.should have(5).items. What would you recommend for the latter, besides players.length.should eq(5) (which might be the clearest alternative – just want to see if you have any other suggestions).

re: the render method, you can pass it the path directly. If you don’t, it uses the argument passed to describe as a convenience. Many Rails devs prefer to not have to type the same thing over and over again, so that feature is provided as a convenience to them (and was requested initially by a Rails dev), but you are not bound by it.

RSpec API - The Good and the Bad posted by Bala Paranj @ Sun, 12 Sep 2010 20:00:13 +0000

Bala Paranj — Sun, 12 Sep 2010 20:00:51 +0000

For example: have(1).items

items is a bubble word. Having the aim to write code like poetry is good. But having unnecessary things in the code that does not do anything adds to the learning curve. It is just noise, adds weight and does not simplify the API.

I see this attitude a lot in the Ruby community: Just because Ruby is dynamic does not mean you should violate all the basics of object oriented design. Parametric coupling is one of the fundamental things to keep in mind, it is not about being subjective or objective. It’s about applying good design principles.

Same thing can be said about constructs like let and subject. When you use those words what happens to the way a developer thinks vs how it needs to be expressed? I have to translate those constructs in my mind to code.

I think the RSpec library has the good and bad probably because only some contributors really get the basics of good API design.

RSpec API - The Good and the Bad posted by David Chelimsky @ Thu, 29 Jul 2010 00:53:31 +0000

David Chelimsky — Thu, 29 Jul 2010 00:54:08 +0000

This is all very subjective. I’ll bet there are some who think the operator expressions are voodoo and that it’s great that they don’t have to write the template name twice in order to get the output they want in view specs.

What are “bubble words”?

RSpec API - The Good and the Bad posted by Bala Paranj @ Wed, 28 Jul 2010 17:56:11 +0000

Bala Paranj — Wed, 28 Jul 2010 17:57:29 +0000

The Good:

Operator Expressions : Good use of meta-programming

The Bad:

1. Have method has bubble words and it complicates the API. It increases the noise in the code. Make the API minimal.

2. Leaky API : render method is leaky because it depends on the argument passed in to the outer method. Basically it has parametric coupling. Developer has to “remember” the coupling in order to use the API. This is very annoying.