[rspec-users] Spec'ing via features

Peter Jaros peter.a.jaros at gmail.com
Mon Nov 24 22:33:58 EST 2008

On Mon, Nov 24, 2008 at 9:41 PM, Pau Cor <lists at ruby-forum.com> wrote:

> I really understand what you are getting at. However, as I less
> experienced developer (my degree is actually in business) I have found
> that having more unit tests (for models and controllers) helps ensure
> that I write better code. I can't think of a single case in which the
> code I write where every public method is tested is not better than the
> code I write where I don't do that.
> Am I unique in this? Or is strict TDD for every public method a good
> practice for someone who is still learning how to design code well?

I feel the same way.  Unit testing for me is as much about writing
better code as about avoiding errors.  As a rule, if i can write clear
specs, I'm writing clean code.

For instance, the Law of Demeter can seem silly at times--Why can't I
just call foo.bar.baz.bax?  But try spec'ing a method which calls
foo.bar.baz.bax and you'll see.  You have to tie yourself in knots of
mock objects to "decouple" from other object's implementations.  Now
you've tightly couples your spec to the implementation of the method,
as well as some other methods.  That coupling is actually a reflection
of a hidden coupling in your code.  The complexity of the tests
reveals a hidden complexity in that train wreck you put in your

It's easy to write bad code without noticing.  It's harder to write
bad specs.  So I write the specs, and I write them first.


More information about the rspec-users mailing list