[Rspec-devel] Nested contexts

[Evgeny]

The reason I suggested this in the first place was that nested setups
is something that is really missing. If I have 3 lines of code that I
just use in each and every setup of each and every context -- then
that is something I would have wanted to have in a separate location.

Ohh well . . . doesn't look like this idea is going to pass anyway :)

On 6/10/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> 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
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>