Forum: RSpec modelling roles and responsibilities

Hi,

reading "Growing Object-Oriented Software, guided by tests", I came
across the distinction of class, role and responsibility.

While classes are classes and responsibilities could be mapped to public
methods, I wonder how to specify roles in my specs. Does anyone have
experiences with this?

cheers,

Nikolay

--
"It's all part of my Can't-Do approach to life." Wally

On Dec 6, 2011, at 2:30 PM, Nikolay Sturm wrote:

>
> Nikolay

https://www.relishapp.com/rspec/rspec-core/docs/ex...

* David Chelimsky [2011-12-07]:
>
> https://www.relishapp.com/rspec/rspec-core/docs/ex...

Sorry, but I don't see how that helps. In my understanding, roles are a
set of related responsibilities. If responsibilities map roughly to
public methods, than a role should be a subset of a class' API. I don't
see where I should want to share example groups.

cheers,

Nikolay

--
"It's all part of my Can't-Do approach to life." Wally

On Dec 7, 2011, at 1:57 AM, Nikolay Sturm wrote:

>>> Nikolay
>>
>> https://www.relishapp.com/rspec/rspec-core/docs/ex...
>
> Sorry, but I don't see how that helps. In my understanding, roles are a
> set of related responsibilities. If responsibilities map roughly to
> public methods, than a role should be a subset of a class' API. I don't
> see where I should want to share example groups.

You can use shared example groups to test a subset of a class's API.

Pat

On Dec 7, 2011, at 4:07 AM, Pat Maddox wrote:

>>>> cheers,
> You can use shared example groups to test a subset of a class's API.
Nikolay - just because they're shareable doesn't mean they have to be 
shared :) As Pat suggests, you can use them to specify a subset of a 
single object's API. That said, one goal of thinking of roles is code 
that is easy to extend thanks to polymorphism. You might have onlly one 
class that satisfies a role now, but you might add another later. Shared 
examples allow you to just drop in a spec for that part of the new 
object's responsibilities.

I blogged about this a while back: 
http://blog.davidchelimsky.net/2010/11/07/specifyi... 
- the focus of that entry is on Modules, but you could just as easily 
think in terms of roles (since a Module often represents a role). The 
stuff about spec'ing the what happens when you include the module 
doesn't really apply, but the stuff about spec'ing similar behavior 
across different objects does.

HTH,
David

* David Chelimsky [2011-12-07]:
> Nikolay - just because they're shareable doesn't mean they have to be
> shared :) As Pat suggests, you can use them to specify a subset of a
> single object's API. That said, one goal of thinking of roles is code
> that is easy to extend thanks to polymorphism. You might have onlly
> one class that satisfies a role now, but you might add another later.
> Shared examples allow you to just drop in a spec for that part of the
> new object's responsibilities.

Ah great, the missing pieces! I hadn't thought about polymorphism and
roles. This finally makes sense. :)

cheers everyone,

Nikolay

--
"It's all part of my Can't-Do approach to life." Wally