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?

On Tue, Jul 15, 2008 at 4:59 AM, Piotr W. [email protected]
wrote:

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” :slight_smile:

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs