Dear All,
Before I know spec’ing, I’ve been practicing testing using JUnit. I
remember that once Kent Beck said (if I’m not mistaken) that we should
not test exhaustively. Instead, we should test until our doubt in the
quality is gone. What about spec’ing? Is spec’ing aimed to create good
documentations or just to remove the doubt? If it is to remove the
doubt, then spec’ing will be pragmatic not exhaustively.
–
~A useful man to others is a lucky man
Rzqies, Order now! http://rzqies.wordpress.com
On Sun, Aug 24, 2008 at 9:44 AM, Muhammad I. [email protected]
wrote:
Dear All,
Before I know spec’ing, I’ve been practicing testing using JUnit. I
remember that once Kent Beck said (if I’m not mistaken) that we should
not test exhaustively. Instead, we should test until our doubt in the
quality is gone. What about spec’ing? Is spec’ing aimed to create good
documentations or just to remove the doubt? If it is to remove the
doubt, then spec’ing will be pragmatic not exhaustively.
Spec’ing, or “coding by example” as we’ve been calling it lately, all
started with TDD. No matter what you call it, or how you approach the
process, the goal is the same: reliable, maintainable software.
Testing “until our doubt in the quality is gone” makes sense to me
regardless of whether you call the process TDD, BDD, testing,
spec’ing, coding by example, etc, etc, etc.
I include “maintainable” in my definition of quality. For me, if code
examples document the code and that documentation makes it easier to
maintain, than those code examples serve to increase confidence (or
remove doubt, if you prefer) in quality.
Make sense?