Untestable Units

Imagine its a few years ago, and you're asked to write a program to disprove Fermat's Last Theorum. Within you code, you have a function:

bool fermatIsWrong(x, y, n) {
  // return true if n > 2 and nth root of (x^n + y^n) is an integer
  // else return false
}

At the time you are writing this function, you do not know whether there exists a set of numbers, {x, y, n} which lead to a true result. (We now know that a valid implementation would be to simply "return false" because the theorum is true; but it is possible to find other examples for which the answer is currently unknown)

Is it possible to write unit tests for such a function?

--DaveWhipp.


Here's an attempt ...

If the nth root of x^n + y^n is an integer, it is surely less than some easily-computed value like, say, x^n + y^n. (Better bound left to the reader.)

Therefore if fermatIsWrong(x, y, n) answers true, this test checks and should return true also:

 sum := x^n + y^n;
 for ( i=1; i++; i<sum) {
  test := i^n;
  if (test == sum) return true; }
 return false;

Similarly for the function returning false.

Had the function computed and thrown away x, y, and n internally, we couldn't have done this. In general, you can't test a function whose answer you don't know. --RonJeffries

Which means, of course, that the definition given on HowDoYouKnowWhenYouAreDone ("you're done when the tests run") is inadequate for this type of software. --DaveWhipp

Of course. If you can't know if the software even works, you definitely can't know when you're done.

EditText of this page (last edited February 13, 2012) or FindPage with title or text search