junit testing a method that invokes an infinite loop

Discussion in 'Java' started by Hoss Spence, Jan 26, 2008.

  1. Hoss Spence

    Hoss Spence Guest

    In this scenario I am getting the next valid event in an infinite
    while loop which sleeps a certain period of time looking for a change
    in state e.g. expected file(s) in the file system that will appear at
    some point and will continuously appear. Question is how would you
    test this? Since you are in an infinite loop, the code once invoked,
    never returns to the junit test. What I landed up doing was stubbing
    the code and putting an iterator in. I have a setter that passes in a
    max so it iterates to the number I want before exiting. Is this the
    best way it can be done? I'm concerned that my actual code isn't
    tested... just the stub but I don't see another way to test this. Note
    I am looking for "state" changes based on different files it finds so
    just invoking the classes beneath don't do the trick.
     
    Hoss Spence, Jan 26, 2008
    #1
    1. Advertising

  2. Hoss Spence <> writes:

    > In this scenario I am getting the next valid event in an infinite
    > while loop which sleeps a certain period of time looking for a change
    > in state e.g. expected file(s) in the file system that will appear at
    > some point and will continuously appear. Question is how would you
    > test this?


    Don't test the infinite loop. The "for(;;)" is Too Simple To Break.
    Instead abstract the content of the loop (minus the sleep too) into
    another method and unit-test that.

    > Since you are in an infinite loop, the code once invoked,
    > never returns to the junit test. What I landed up doing was stubbing
    > the code and putting an iterator in. I have a setter that passes in a
    > max so it iterates to the number I want before exiting.


    Why is repeated execution of the same code necessary?
    If the loop content does a state change, you should test each
    state change for itself. Being in one of a number of recognized
    states between loops would be an invariant of the loop.
    It need not be tested (or rather, it's tested by testing that
    the loop body preserves the invariant).

    > Is this the best way it can be done? I'm concerned that my actual
    > code isn't tested... just the stub but I don't see another way to
    > test this.


    You don't need to test all your code. 100% coverage is a sign of
    somebody not understanding why they are doing unit tests (it's not to
    increase your coverage percentage!)

    I would separate the code into:

    - the loop, including the sleep.
    - the condition checker (the one checking for files, etc)
    - the state change logic itself (go from state A to state B)
    - the dispatch logic (based on conditions from condition
    checker, call the appropriate state change logic)

    The dispatch logic is parameterized by implementations of
    interfaces for condition checking and state change. For unit
    testing it, use mock implementations that checks that the
    for a selected condition, the correct state change logic is
    called.

    Check the condition checker and state change logic by
    itself.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jan 26, 2008
    #2
    1. Advertising

  3. Hoss Spence

    Hoss Spence Guest

    On Jan 26, 4:08 pm, Lasse Reichstein Nielsen <> wrote:
    > Hoss Spence <> writes:
    > > In this scenario I am getting the next valid event in an infinite
    > > while loop which sleeps a certain period of time looking for a change
    > > in state e.g. expected file(s) in the file system that will appear at
    > > some point and will continuously appear. Question is how would you
    > > test this?

    >
    > Don't test the infinite loop. The "for(;;)" is Too Simple To Break.
    > Instead abstract the content of the loop (minus the sleep too) into
    > another method and unit-test that.
    >
    > > Since you are in an infinite loop, the code once invoked,
    > > never returns to the junit test. What I landed up doing was stubbing
    > > the code and putting an iterator in. I have a setter that passes in a
    > > max so it iterates to the number I want before exiting.

    >
    > Why is repeated execution of the same code necessary?
    > If the loop content does a state change, you should test each
    > state change for itself. Being in one of a number of recognized
    > states between loops would be an invariant of the loop.
    > It need not be tested (or rather, it's tested by testing that
    > the loop body preserves the invariant).
    >
    > > Is this the best way it can be done? I'm concerned that my actual
    > > code isn't tested... just the stub but I don't see another way to
    > > test this.

    >
    > You don't need to test all your code. 100% coverage is a sign of
    > somebody not understanding why they are doing unit tests (it's not to
    > increase your coverage percentage!)
    >
    > I would separate the code into:
    >
    > - the loop, including the sleep.
    > - the condition checker (the one checking for files, etc)
    > - the state change logic itself (go from state A to state B)
    > - the dispatch logic (based on conditions from condition
    > checker, call the appropriate state change logic)
    >
    > The dispatch logic is parameterized by implementations of
    > interfaces for condition checking and state change. For unit
    > testing it, use mock implementations that checks that the
    > for a selected condition, the correct state change logic is
    > called.
    >
    > Check the condition checker and state change logic by
    > itself.
    >
    > /L
    > --
    > Lasse Reichstein Nielsen -
    > DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    > 'Faith without judgement merely degrades the spirit divine.'


    Some good advice... my mocked stub is basically doing what you're
    suggesting but a bit contrived. I guess the thing that bothers me is
    at some point I'm used to testing the whole app... but in this case I
    have to be satisfied with testing the biggest parts I can.
     
    Hoss Spence, Jan 26, 2008
    #3
  4. Hoss Spence

    ankit200490

    Joined:
    Feb 29, 2012
    Messages:
    1
    Can anyone show the example for testing simple loops(for,while,do while) especially "for" loop in java.
     
    ankit200490, Feb 29, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Don
    Replies:
    0
    Views:
    4,351
  2. Mich
    Replies:
    5
    Views:
    539
  3. Replies:
    5
    Views:
    602
    benben
    Jan 31, 2006
  4. Replies:
    4
    Views:
    419
    Salt_Peter
    Oct 12, 2006
  5. Isaac Won
    Replies:
    9
    Views:
    387
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page