Re: TDD: Test-Driven Design or Test-Driven Development?

From: Vladimir (NspamOtrushkin_at_tut.by)
Date: 02/03/04 

Date: Tue, 3 Feb 2004 17:36:03 +0200

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:S1NTb.3207$yE6.1086@newssvr31.news.prodigy.com...
> Vladimir wrote:
>
> > I will never get tired of repeating...
> >
> > If you intent to get tests pass you'll succeed. If you then approach
> > software with intention to make it fail you'll succeed again. Wow!
> Amazing!
> > :)
>
> "If you are curious, or code does something unexpected, or you receive a
bug
> report, always write a new test. Then use what you learned to improve
> design, and write more tests of this category. If you treat the situation
> 'this code does not yet have that ability' as a kind of bug, then the TDD
> cycle is nothing but a specialization of the principle "capture bugs with
> tests".
>
>
>
> "But this power creates new risks. If all your tests request bugs, if you
> leave huge matching gaps in testage and code, and if you never refactor
your
> code but leave it crufty, frequent testing will also aggressively support
> these activities, and provide a very high apparent velocity.
>
>
>
> "Teach your colleagues to write tests on your code, and learn to write
tests
> on theirs too. If they write a test that fails due to missing abilities,
not
> faults in deployed abilities, treat the failing test as a feature request,
> and get it prioritized."
>
>
>
> You are playing the familiar "declaim one practice in isolation from the
> others" game. The White Book also covers that.

Honestly I didn't get what you are trying to convey...

I was just guarding the principles being IMO key to all testing. I know this
for sure that scarce testing is no much better than no testing at all. All
you do is examine a bit there a bit here and end up with some test suit that
never give you an idea about software quality. In other words you leave
holes of unexamined conditions that user may get into afterwards.

Demonstrating tests are good at regression testing. But regression testing
is what usually comes *after* some-other-type-of-testing
(unit/integration/system) and being composed of tests derived from those
suites designed WITH INTENTION TO FIND DEFECT (not showing the code is
working).

This time I suppose I was clear enough. 

----
Best Wishes,
Vladimir

Relevant Pages

  • [Full-Disclosure] Shiver me timbers.
    ... my point of view, I'm not intending to tell anybody, ... A security vulnerability is a specific type of bug with specific types ... The only difference I see in the security sector is that there is the _intention_ ...
    (Full-Disclosure)
  • Re: [kde] media:/ copies videos
    ... What happens if you hover over a video in just a normal local path? ... is that konq is trying to make a preview, and there's a bug in the video ... Got no intention uf upgrading here tho, ...
    (KDE)
  • Re: Repetitive XML comments -- whats the point?
    ... but the actual could be the correct behavior and the intention ... What defines a "bug" is the degree to which a program ... finally in method E I discover that the original design was to handle ... original author intend that this method explode when passed a null... ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [PATCH] Added MIPS RM9K watchdog driver
    ... so it's probably a bug. ... and expresses the intention clearly. ... My meager understanding is that it makes the kernel image bigger. ...
    (Linux-Kernel)
  • Re: "Programming Ruby", ed. 2, P747. Script generated different image to books example
    ... Its intention is to "show off" the abilities of Tk and widgets. ... The script works but generates a different image to that shown in the book What results do you guys have? ...
    (comp.lang.ruby)