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.