How to test an algorithm with multiple inputs?

Question

I want to check group of algorithms which has up to 8 input options. The native idea would be to check all possibilities via brute force. How can I reduce it without leaving out required combinations?

Since I do not know it better I'm using multiple loops which ends in worst case in a O(n8) complexity.

To give a hint what that inputs are:

• Data point count (by default 28 but can be 14-70 or anything else> 5)
• Date (s relative day index based on the data points)
• Preferences (limited to 3)
• Temperature (limited to 34-38°C in 0.05 steps)
• A marker on a day (limited to the possible values from the data points)

I have multiple algorithms which have all the same interface, but some concrete algorithm just uses some fields and not all. However should I need to check those other cases too since the algorithm might been updated and the test was forgotten for some reasons?

Do you have some best practices how to check algorithm?

• gnat: Possible duplicate of How should I unit test mathematical formulae?
• rekire: @gnat well also Unit testing for a scientific computing library is related but both do not really help me. I'm still not sure if what I did makes sense or if that was just a wast of time. Uh that banner is confusing me. Is my question already closed?
• Kilian Foth: Try to at least ensure path coverage for each algorithm. That means you have to give up the black-box nature of your tests, but coverage is more important.
• rekire: coverage of cause!
• gnat: no, not closed: meta.stackexchange.com/q/250981/165773

Answer 1

You should write tests for the logic as it is now - not how it might be later on or for some hypothetical test case.

Unit tests are supposed to be fast, so concentrate on the racing line tests and those at the limits of the parameters.

If the sheer number of cases is causing you concern, some unit testing frameworks such as NUnit allow you to specify a range of values and spawn a test for them all. It can also crunch combinations of parameters. So say you had parameters X and Y where X could be 1 or 2, and Y could be 1-5, it would create all possible cases for you.

If you do wish to test all possible combinations, that is perfectly acceptable but should probably take place outside of the normal development unit test run cycle. Perhaps as integration or soak tests that are say, run once every build/week etc.

• rekire: Would you be so kind to add a small NUnit example or maybe just link it? I never used that library.
• Robbie Dee: The documentation has some pretty decent examples in it. An example of using Range. Also an example of using Combinatorial.
• rekire: Ah, this is a C# library I'm using java. Do you know an equivalent?
• Robbie Dee: I believe it is a functional clone of JUnit