Testing IComparer Implementation

[ckarbass]

I am testing a comparer class that implements IComparer. The comparer
constructor takes as arguments a property field which can take on lets
say roughly fifteen values. It also takes two other boolean arguments.

Testing all permutations of the comparer doesn't seem practical. Are
there any suggestions for testing the comparer? Do I need to test all
permutations?

Thanks in advance for any advice.

 

[Gabriel Lozano-Morán]

Depends on what your code does. If you have different execution paths based
on the values passed as an argument I would say yes.

Gabriel Lozano-Morán

 

[Mark Wilden]

I am testing a comparer class that implements IComparer. The comparer
constructor takes as arguments a property field which can take on lets
say roughly fifteen values. It also takes two other boolean arguments.

Testing all permutations of the comparer doesn't seem practical.

Is the number of permutations 4 x 15? That doesn't sound too bad, especially
if you can make it table-driven.

Are there any suggestions for testing the comparer? Do I need to test all
permutations?

Are you a professional tester or a programmer? If the former, then yes, you
have to test all the permutations. Otherwise, my advice is to test
everything that could break.

///ark