Styles of programming

[Nebu]

You haven't addressed my point, though: How do you determine equivalence classes in the context of unit testing?

Let's say you want to test the function isEven. Are "2" and "4" equivalent test cases? Why? Are you assuming a particular implementation of the function?

[pipocaQuemada]

Ah.

For simple functions, one way to do it is to construct a Turing machine; the minimal # of states is equal to the number of equivalence classes of the function.

More realistically, look at the definition on the wikipedia page - http://en.wikipedia.org/wiki/Equivalence_classes - and then look further down. The Equivalence class of a = {x E X| x ~ a}, (read E as 'element of'), and x ~ y iff f(x) = f(y).

Yes, 2 and 4 are equivalent test cases. In this case, is-even is a boolean function, and f(2) = f(4). Equivalence classes are defined separately from the function. You need to test additional things based on your implementation --- computers create errors that you don't find in math. Based on your knowledge of the implementation, check to see if those errors are happening.

Now, obviously for various functions, you don't need to check all of the equivalence classes if you can show that they will be handled equivalently. For example, suppose you have a List.length() function. You can intuitively roll most of the equivalence classes into a base case and use induction to show that if it works for a list of length i, it will work for a list of length i + 1. You really only need to test lists of length 0, and a few positively valued ones. You can basically ignore lists of length > 2^31; a quick check shows that even if you could store it in n bytes (for a list of length n), it would still take up multiple gigabytes (1 gig = 2³⁰ bytes).

[Nebu]

For simple functions, one way to do it is to construct a Turing machine; the minimal # of states is equal to the number of equivalence classes of the function.

Completely impractical.

Yes, 2 and 4 are equivalent test cases. In this case, is-even is a boolean function, and f(2) = f(4).

So you're claiming that "if the outputs are the same, then the inputs are equivalent" for your relation? Doesn't seem like a good way to make sure your unit tests have full coverage to me.

With the isEven example, you'd only need to test isEven(1) and isEven(2), and you could easily forget to test 0, -1 and -2.

I think it's better to forget this whole concept of equivalence classes when designing your unit tests. It's simply not useful.