Parsimony and Context
Posted: Sep 3, 2005 2:10 PM
> My thesis: given two design which accomplish the same
> thing, the one which requires fewer tests is a better
That's an arguably laudable goal but:
* It's a post hoc measurement. I.e., as I noted in the previous thread, if you're actually developing software (TDD-wise) how do you know what test is "necessary" and which one isn't until after you've developed the software? If you're doing post-coding testing then hopefully it's already obvious that that's post-hoc. But note that even in post-hoc testing, you don't a priori know the minimal set of tests to perfectly cover a system (think: halting problem).
* It presupposes a static view of the system. I.e., systems are dynamic and evolving. So there's always going to be a rhythm between necessary and sufficient code/tests/etc. That's a fundamental point of the value of "refactoring" as a key building block of TDD. The "designer" mindset is heavily biased towards these sorts of static views but hasn't the success of the agile movement made it popularly clear that dynamic, adaptive evolution
is the fundamental reality of software systems?
> This I believe to be true from either a Quality
> Assurance (QA) point of view, or a TDD point of view. This
> is why I say that we want to somehow strive towards
> elimination of tests in our designs. When it is possible
> to forecast the number of tests required for a design
> decision, in theory it should make it easier to make
> design choices. Perhaps this could lead to software which
> makes design decisions, though this is probably pretty far
> out there.
I totally concur that refactoring the tests is important -- almost as important as refactoring the code, IMHO.
Also, as I noted in the previous thread, if you care about precision in correctness then using assertive checking (e.g., contracts (ala Design by Contract)) is a *necessary* adjunct to the various levels and types of use-tests.
> My previous conflation of TDD and QA was somewhat
> intentional, because I think that QA is automatically a
> goal of any programmer, and any methodology. I assert that
> the biggest advantage of TDD by itself is QA through
> incidental correctness testing.
Bah, again. :-)
IME, the biggest value of TDD has been getting developers to shift their focus to a much finer iterative level and a more actual-use feed-forward/-back mindset. Quality is just one of the by-products.
> A development methodology in of itself is useless, unless
> it helps us achieve our goal as programmers:
> Writing correct software in the shortest amount of time.
Is that really the job of programmers?
Hmm... Perhaps you're implying a lot into the word "correct"...
Strategically, what's the "correct" things to do for the needs of the e.g., business? I.e., "Doing the right things." Often, that's *not* doing that project (as specified).
Once there's a strategic need then the focus is tactically on "doing things right." That's my impression of what you're talking about.