rspec users - Jul 2008 - Specyfing behaviour VS specifying implementation

At first it seems obvious: one should specify behaviour, not
implementation.

However, there may be a tremendous overhead and duplication with such
approach.

Let''s assume:

def a
  # lot''s of business logic
end

deb b
  # lot''s of business logic
end

def main
  a
  b
end

Assuming we do have specs for methods a and b, how the main method
should be specified?

1) Full behaviour specification
   Problem: it duplicates specification of a and b

2) Specify that main should call a, then b
   Problem: it specifies implementation, NOT behaviour


So, what is the right way?
-- 
Posted via http://www.ruby-forum.com/.

On Tue, Jul 15, 2008 at 4:59 AM, Piotr Wlodarek <lists at ruby-forum.com>
wrote:
> At first it seems obvious: one should specify behaviour, not
> implementation.
>
> However, there may be a tremendous overhead and duplication with such
> approach.
>
> Let''s assume:
>
> def a
>  # lot''s of business logic
> end
>
> deb b
>  # lot''s of business logic
> end
>
> def main
>  a
>  b
> end
>
> Assuming we do have specs for methods a and b, how the main method
> should be specified?
>
> 1) Full behaviour specification
>   Problem: it duplicates specification of a and b
>
> 2) Specify that main should call a, then b
>   Problem: it specifies implementation, NOT behaviour
>
>
> So, what is the right way?
The right way is to write examples of behaviour BEFORE you write the
code so you don''t end up with two methods with "lots of business
logic" :)

If you''re writing examples first, then you''d have examples for
:main
and, as :main grew in complexity, :a and :b would be extracted from
:main.

If :a and :b are methods intended to be part of the public interface
of the class, then perhaps they belong on another object, in which
case setting message expectations on a mock is perfectly acceptable
for examples of :main.

HTH,
David