[rspec-users] Spec'ing via features

Pat Maddox pergesu at gmail.com
Mon Nov 24 17:40:41 EST 2008

Shane Mingins <smingins at elctech.com> writes:

> On 25/11/2008, at 7:29 AM, Pat Maddox wrote:
>> Lately I've been putting more and more stuff into ATs.  I'm finding it
>> valuable to keep tests for domain logic separate from plain ol unit
>> tests...meaning that my Account object may be tested mostly with
>> Cucumber, but helper objects such as a stats aggregator will be spec'd
>> with code-level examples.
>> Pat
>> _______________________________________________
> Just wondering a bit on this ... the bit about your Account object
> being tested mostly through Cucumber vs unit tests.
> In my mind (as I think about this) cucumber is more about testing than
> rspec is, meaning Acceptance Tests are more about testing where unit
> tests when using TDD is more about design than testing.  Do I make
> sense?  Email is not the best medium for conversations :- )
> Now from what I have read of your writings I am assuming that you are
> using TDD .... and so just from what I read above I am wondering if
> that statement is true because TDD is driving the implementation of
> Account, and so you will have a 100% coverage of the Account class
> behaviour, but when it comes to testing, the AT is doing more of that
> (meaning testing).  Is that it?   IIRC, in Kent Beck's TDD book there
> is the example of TDD'ing a triangle (or something), but it was
> something that showed that to TDD the triangle you ended up with less
> tests than if you were testing the triangle.
> How's that sound?
> Cheers
> Shane
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Here's my latest Theory of Testing, in a nutshell:

Logic in a system falls into one of two categories, business logic and
supporting (infrastructural?) logic.  Business logic is often then
further subdivided into domain logic and application logic.  Domain
logic is the logic essential to the domain being used and would remain
consistent between applications, whereas app logic is unique to each
application.  Most domain models I've seen used in Rails apps are used
*only* in that Rails app, and tend to be simple enough, that this
distinction doesn't matter a whole deal.  Well, actually I think Rails
devs just don't think in those terms, but whatever.

It's this business logic that is important to capture in acceptance
tests, in my opinion.  We can write ATs for domain logic, as with the
example I gave for the ATM withdrawal.  And we can also write ATs for
application logic, which is stuff like showing a success message on a
page, or sending off an email, or whatever.

I think some of the confusion comes from "edge case" having a pretty
particular meaning to developers, but in the example I gave there's a
lot of overlap between an important business scenario and a programmer's
edge case.  I'm finding that when that occurs, and I can be confident in
my code after writing acceptance tests to cover the business scenarios,
I don't need to write object examples.

Then there are a bunch of objects that provide neither domain nor
application logic - they're basically just the result of refactoring to
keep your design clean.  These are the objects I write examples for.
They don't matter to the customer, but it is important to me that they
work and are well-designed.  And actually, I'm starting to relax on
those a bit as well sometimes...Yehuda advocates a style that is
basically JUST acceptance testing (though at various levels, because
sometimes the "customer" is a business user and sometimes it's another
programmer using your API).  While I don't go as far as he does, I am
less strict about directly testing every single method of every single
object than I was just a few months ago.

Wow, if that's it in a nutshell... :)


More information about the rspec-users mailing list