[rspec-users] Specifying that code is called in a block
dchelimsky at gmail.com
Fri Mar 2 12:01:33 EST 2007
On 3/2/07, Bryan Helmkamp <bhelmkamp at gmail.com> wrote:
> On 2/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > I can't help but feeling that if you're specifying behaviour at this
> > level of detail you're too specific. You're testing implementation,
> > not verifying behaviour.
> Is there an alternate solution you'd propose, or would you go without
> this spec entirely? It's easy to imagine a case where the lack of
> specifying the need for a transaction could allow a bug.
If it's easy to imagine the case, then it _should_ (in theory ;) ) be
easy to write a spec that exposes that bug.
> More generally, what metrics do you apply to differentiate between
> testing implementation and verifying behavior?
> As I understand it, if one were to follow a strict spec-first style of
> development, each piece of implementation would have to demanded by a
> failing spec before it could be written. In this particular case, that
> would mean not adding the transaction block until there is a unit spec
> requiring it. How do you reconcile these two seemingly conflicting
TDD is not a perfect world, and BDD certainly does not make it so.
There are cases in which we know things are important and we do some
ugly things to test them.
Bob Martin puts something similar into perspective talking about
comments. He says that once in a while he'll put a comment somewhere
because it is more pragmatic to have the comment than any alternative,
but that he views that as a failure. He doesn't let it stop the world.
He simply acknowledges that something is wrong and presses on.
Similarly, in this case, absent a viable solution using the available
tools, I'd probably do some nasty stuff to spec this out, but catalog
that in the back of my mind as a failure of some combination of my
skill and the available toolset.
Tools like rspec are there to help you, and often do. But when they
don't, you can't let that be an excuse for not producing software that
is solid, maintainable, and meets the requirements at hand.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users