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

Re: [XP] Test-first an infinite loop

Expand Messages
  • Bill Caputo
    ... Not all, I loved it. My reply wasn t meant to be sarcastic, I actually do suspect a test can t be written -- but to clarify, I ll restate the ... The
    Message 1 of 31 , Apr 4, 2010
      On Sun, Apr 4, 2010 at 11:11 PM, Adam Sroka <adam.sroka@...> wrote:
      > Sorry for being flippant with my allusions ;-)

      Not all, I loved it. My reply wasn't meant to be sarcastic, I actually
      do suspect a test can't be written -- but to clarify, I'll restate the

      > The problem you've stated is to prove that something doesn't happen ever.

      The problem I've been trying to get at is: Is there a test that, when
      written allows for an implementation that resembles: while(true) do
      stuff; ?

      BTW, my interest in raising this question isn't so much about whether
      we can ensure something does or does not happen but rather the notion
      that this bit of code can't be written test-first (or at least I
      haven't found a good way). I can (and will) ensure that various other
      code needs are specified in tests (specs, whatever) before
      implementing, but there is no test that I can think of where "loop
      forever" makes it pass.

      > You need to ask a different question. I would start with something like: "If
      > this loop were to exit, what is the most likely reason why?" Then, "what is
      > the second most likely reason?" Etc. until you run out of plausible ideas.

      If my goal were assurance that the code works, I would (and do) agree,
      but what I am angling in on is the narrower idea of can we write a
      test where making it pass is writing the implementation "while(true)
      do stuff" and if not what are the consequence?

      Put another way, I use TDD for driving out implementation (assurance
      is something else and doesn't concern me here). Whenever possible, if
      my tests aren't asking me for a line of code, I don't write it.
      However, I can't find a test that will let me write this code, so I am
      stuck - well, not really because I can just implement the loop - but I
      am forced out of my test-code-refactor process (or through some hoops
      that aren't worth it) and so am interested in different ways (if at
      all) people have gotten to such an implementation test-first. Make
      more sense?

    • 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
        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

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