[Rspec-devel] Nested contexts

[aslak hellesoy]

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> From: "David Chelimsky" <dchelimsky at gmail.com>
>
> > Structures like nested contexts are going to
> > lead to degredation in clarity
>
> I am curious what this is based on.
>
> If it is based on the experience with the x-Unit family then is that really
> the right comparison? The best written and most readable specs I have seen
> (not in the context of TDD) have very clear nested tables of contents. Not
> everything fits this structure, but it helps more than enough that I would
> hate to read or maintain those specs as a 2-level flat list.
>
> Some uses of that nesting are for things that may not correspond to (say)
> chains of initializers (r-spec setups). I think that is a separate matter.
> If the structure is useful enough, why rule it out? Why not figure out the
> variations in its use?
>
> > I do think that we'll have to address the duplication issue at one
> > point,
>
> What kind of ratio do you expect (in the very near term) for:
>     Lines-of-Spec / Lines-of-Code
>

I'd recommend using a tool like RCov (which RSpec's Rake task supports
out of the box).

While usage of a coverage tool cannot prove that you have covered
everything there is to cover, it can identify when you haven't.

As a rule of thumb I'd recommend at least 2 specs per method in the
'outer' parts of an API. At least one for the happy path and at least
one for the unhappy one.

Example: If you're developing an RDBMS, your 'outer' part would be the
code that is 'close' to the client interface - i.e. the code parsing
the SQL. You should have specs that cover the cases when the SQL is
valid, and when it's not. If you get this right, you can be more
relaxed about specs for the 'inner parts' - the code that gets
executed once the SQL's correctness is verified by the outer part. You
don't have to specify unhappy paths as much when you get to the
innards of your code - because you can assume that it won't receive
'bad' method calls and data.

BDD and RSpec are design tools, not testing tools. You write specs to
figure out what code you need to write. You start with specs because
they are designed to be closer to how humans think. They help you
write better code.

> Isn't there evidence that the ratio is close to 1, or even > 1?

I don't think that is possible to prove. AFAIK we still don't have any
axioms to base a proof on.

Aslak

> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>