How big should be an input array to unit test a method with a loop? [closed]

Question

This probably sounds like a dumb question, forgive me if I'm asking this in the wrong place, I'd be happy to delete it if so. I'm sort of new to unit testing and I'd like to learn best practices regarding this question, it's been bugging me for a while.

Assume that there is a method which takes an array as the input and performs some algorithm to its elements. There may be a situation where the method is called repeatedly with input containing elements that have already been processed by the object (and remembered somewhere). I'd like to test that the method doesn't process the same input elements twice, i.e. that it does nothing the second time it encounters those items.

The object under test is actually a wrapper around another object that is provided as a depencency to it, so I can mock that object and verify that the necessary processing methods are called.

So my question is:

How many input elements would you consider to be "enough" to in order to test that the method works properly (for both old and new elements)? One? Three? Ten?

Answer 1

What you describe is something of the form:

for elt in list loop
  if unprocessed(elt) then process(elt) end loop
end loop

What you REALLY have is something of the form

for elt in list loop
   maybe_process(elt)
end loop

where

proc maybe_process(elt) is
   if unprocessed(elt) then process(elt) end if
end proc

LISPers will immediately recognize the second form as MAPC, which takes a function and applies it to each element of a list.

At that point, your original problem is decomposed into two much simpler problems, that of calling an ARBITRARY function on each element of a list, and that of writing a function that can take an element, determine whether it has already been processed, and, if not, process it. The first function takes as few elements in the list as you need, I'd probably use three. The second function takes as many individual test cases as you need to check out the two pieces of the pie.

Even if you decompose it in the first form, you can use very simple test functions to check out the loop, and then a very simple process() function to check out the unprocessed() predicate.

The key is that you can use MUCH SIMPLER functions to do your testing phases.