1

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?

rekire
  • 113
  • 6
  • Possible duplicate of [How should I unit test mathematical formulae?](http://programmers.stackexchange.com/questions/272938/how-should-i-unit-test-mathematical-formulae) – gnat Oct 19 '15 at 10:39
  • @gnat well also [Unit testing for a scientific computing library](http://programmers.stackexchange.com/q/188442/200819) 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? – rekire Oct 19 '15 at 10:44
  • 1
    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. – Kilian Foth Oct 19 '15 at 10:49
  • *coverage* of cause! – rekire Oct 19 '15 at 10:50
  • no, not closed: http://meta.stackexchange.com/q/250981/165773 – gnat Oct 19 '15 at 10:51

1 Answers1

2

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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • Would you be so kind to add a small NUnit example or maybe just link it? I never used that library. – rekire Oct 19 '15 at 11:09
  • The documentation has some pretty decent examples in it. An example of using [Range](http://www.nunit.org/index.php?p=range&r=2.5). Also an example of using [Combinatorial](http://www.nunit.org/index.php?p=combinatorial&r=2.5). – Robbie Dee Oct 19 '15 at 11:15
  • Ah, this is a C# library I'm using java. Do you know an equivalent? – rekire Oct 19 '15 at 11:21
  • 1
    I believe it is a functional clone of [JUnit](http://junit.org/) – Robbie Dee Oct 19 '15 at 11:28