On Jan 8, 2008 11:25 AM, Matt Patterson <matt-lists at reprocessed.org> wrote:
> On 8 Jan 2008, at 19:14, Daniel Tenner wrote:
>>> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously close to specifying how the object does its
> > business, rather than what it does.
> >
>> If you're a proponent of many-skinny-methods then you wind up with a
> lot of public methods which should never need to be called by another
> object, so making them private can be a good thing for general users
> of the object.
There are several problems with this thinking:
1. It separates refactoring from BDD. Having several private helper
methods is a result of refactoring. Refactoring is not only a design
tool, but a central part of BDD.
2. It couples your specs too tightly to the implementation. If you
rename/delete/add a private method, you need to update the spec, even
though the object's public behavior didn't change.
3. It eliminates the effectiveness of specs as documentation. Reading
the specs is one of the first things I do when examining some code.
If I see examples of how to use it, except not really, because they're
private methods, I'm going to be seriously confused or seriously
pissed off.
4. It leads to violations of the "one defect, one broken test"
guideline. Some spec that exercises public behavior covers this
private method, as does its individual spec, so if it breaks, then you
have two broken specs. Whether that's important is a matter of
personal preference.
There is no 1:1 mapping of specification example to method. You don't
specify a method. You specify a behavior. There are no rules
dictating the specification's granularity, as long as it helps you
design your code in the beginning, and localize defects as your code
base persists.
Specifying private methods is, in my opinion, slightly less pleasant
than week-old trout in my pillow. It means one of two things. At a
code level, your method's visibility could just be off. At a
conceptual level, you may be missing the point of BDD entirely.
Pat