A lot of the time it's easier to confirm that an answer is correct than compute that answer. Imagine a test like:

    val result = factorize(367)
    assertEquals(367, result.reduce(_ * _))

This isn't really a "human validation" - as a human I don't actually know what the prime factorisation of 367 is - and the sense in which it's a "compiler rule" is a deep and subtle one. But I'd argue that it's a valid test and quite a lot of software tests are of this type.

Another type of test not considered here is a "redundant" check for a simple case. If we write a test like:

    assertEquals(multiply(83, 83), pow(83, 2))

then to a certain extent that's redundant, but I'd argue it's a useful sanity check of our pow implementation. Again it doesn't seem right to call this a "human validation" since I don't actually know 83^2 as a human.

It also bears considering that even an entirely redundant test may be useful in providing (and explaining) a use case for an API. If we've just implemented the map() function for lists, then a test like:

    def f(x: Int) = x * 2
    val input = List(1, 2, 3)
    var result = List.empty()
    for { element <- input }
      result :+= f(element)
    assertEquals(result, input map f)

is "redundant" in this taxonomy, but a perfectly legitimate test of map; often "be equivalent to this more complicated sequence of functions" is exactly the specification of a particular function.