junit testing a method that invokes an infinite loop

[Hoss Spence]

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.

 

[Lasse Reichstein Nielsen]

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

 

[Hoss Spence]

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.


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).


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

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.

 

[ankit200490]

Can anyone show the example for testing simple loops(for,while,do while) especially "for" loop in java.