Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Test-first an infinite loop

Expand Messages
  • Bill Caputo
    So, in summary: Short of hitching a ride on the heart of gold while eating some fairy cake (in a hot tub), we are left with acknowledging that we ve run smack
    Message 1 of 31 , Apr 4, 2010
    • 0 Attachment
      So, in summary: Short of hitching a ride on the heart of gold while
      eating some fairy cake (in a hot tub), we are left with acknowledging
      that we've run smack into the Halting Problem and should move on to
      test other things that can possibly break (or ask either Douglas Adams
      via seance or Alan Turing via Neal Stephenson for guidance).

      I'm OK with that (like I mentioned, I've taken that approach in the
      past), but I'm left with a question (I'm going philosophical here, so
      all of you who just do TDD to get work done can safely ignore this):

      Aside from the verification aspects, there is a pure TDD (i.e. Design)
      aspect to consider: Can such a loop ever be introduced into code
      test-first? And if not, what consequences (if any) does this imply?

      For example: Should we add an explicit: Test-first everything that can
      possibly break except implementations that aren't expected to
      terminate, in which case you can ignore this rule and apply TSTTCPW to
      inspect the code (much like UI code is often punted) and get on with
      your life (the path I plan to take tomorrow incidentally, when I
      introduce said loop into the code we are working on) when we teach
      others TDD?

      Thanks, all

      Bill
    • Bill Michell
      Well, an infinite loop is definitely a special case construct - not something that you want to see in normal usage. Sounds like what we are looking for is a
      Message 31 of 31 , Apr 9, 2010
      • 0 Attachment
        Well, an infinite loop is definitely a special case construct - not something that you want to see in normal usage.

        Sounds like what we are looking for is a good use case - maybe a daemon that keeps running some processing method even when given no time by the current thread.

        So I'd make the processing method simply increment a counter.

        The first test just sets the counter to 0 and spawns a thread that runs our main method. The test then checks that the counter value eventually becomes at least 1 - and hence that our processing method got called. Note that spawning the thread is probably part of the test, not the method under test.

        No loop required - just a call to our processing method.

        The next test spawns the thread again, but this time checks the counter eventually becomes at least, say, 10.

        I'd posit that the simplest way to pass the test is to surround the worker method call with a while(1) construct. If you wanted to go via ten calls to the worker method first, knock yourself out.

        For completeness, I'd probably write a test that checks the counter with a decent time interval between the checks, and show that the counter value was continuing to increment. If you haven't reached while(1) already, then this test will surely get you there...

        Yes, it isn't a fast test, and yes, it involves spawning threads. Not pretty. But I'd argue that you are working with a special use case here - even though on the face of it, the construct is a really simple one. It also gives a nice clean design (separating the "never stop" from the "processing" stuff) that lets you do nice things like checking error conditions and termination conditions if those ever become interesting.

        On 8 Apr 2010, at 23:09, Tom wrote:

        > Eggzackly - hence my hesitation.
        >
        > --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
        > >
        > > On Thu, Apr 8, 2010 at 11:06 AM, Tom <rossentj@...> wrote:
        > > >
        > > >
        > > >
        > > > I hesitate to suggest such ugly complexity - but ... maybe have the test start the target in a separate thread which it can kill when it's satisfied ... in a "finally" clause, of course....
        > > >
        > >
        > > At which point it may no longer be the simplest thing that could
        > > possibly work ;-)
        > >
        > > How would you change the test so that it was?
        > >
        >
        >

        --
        Bill Michell
        billmichell@...






        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.