# Equivalence class for this requirement

The automated bell system of Stateless University should ring every hour during Mondays, Wednesdays, and Fridays. It should ring every 90 minutes during Tuesdays and Thursdays, and does not ring at all during weekends

So the equivalence classes for these are:

Mondays, Wednesdays, Fridays

Tuesdays and Thursdays

Saturdays and Sundays

90 minutes

60 minutes

Am i right?? or am i missing something?

-

Using equivalent class on discrete values seems not be to a good idea. This is event more risky if the number of possible discrete values is small (like days).

The reason is the following: If you define an equivalent class, for let say {Mondays, Tuesdays, Wednesdays}, you hope that testing only 1 of these days will be sufficient to test the software behaviour, and that you won't have to test the 2 others.

The risk comes from developper choice:

(1) If the developper write a test like ' if (Mondays <= day) && (day <= Wednesdays)', equivalent class would work, because every day in the range will behave the same way.

(2) Unfortunatly if the developper write a test for every day, testing only 1 day with the following does not completly test the implementation: ' if (Mondays == day) || (Tuesdays== day) || (Wednesdays== day)' The reason being that you didn't test every condition.

The real case I have in mind is the following:

We had a software component doing a discrete delay, of 1 to 8 samples. The test case was written using equivalent class on the numberOfSample variable, which values are in the range [1..8]. Thus tests were made with 1, 3 and 8 (plus 0 and 9 for robustness testing).

The problem is the following: For performance reason the developper wrote a price of code for each 1 to 8 case, with a switch case in front. Thus some part of the code were not tested, and the structural coverage for this component was below 50%. I had to explain the implementation choice, and test case now tests every value from 1 to 8, and we applied the same principle for every similar variable.

If the software implementation has a very discrete input, with a limited number of possible values, don't try equivalent class (Moreover, you should really not do it if values are not continous).

If the software have an almost continous input, like for example, the number of seconds since the begining of the week, there is many chances that the software behaviour will be the same for the range of a few continous days. If not, the behaviour should be consistent at least within a single day (you will test at 0:00, 0:01, 15:34, 23:59, for every given day).

-
"Using equivalent class on discrete values seems not be to a good idea. " I'm not sure discretion is a good criterion/justification here. You may have integer values from 0 to 2^16, and integers are discrete, but testing all of them might cost much. – dzieciou Feb 3 '13 at 16:35
You are right, technically our computers only handle discrete values. I should clarify my position, discretion of the represented value (not the internal computer representation) could be a criteria. In the [0;2^16] integer example, i think that this integer encode an almost continous (or non enumarable) quantity, like time, distance, intensity ... – Marc-Emmanuel Coupvent des Gra Feb 3 '13 at 19:17
So according to your criterion, testing a function that returns a sign of an integer (+, 0, or -) should be tested on all possible integers? I don't think so. And in mathematics, integers are considered discrete numbers, and real numbers are considered continuous, because you may always find an real number between two real numbers, while the same is not true for integers, e.g., there is no integer between 8 and 9. – dzieciou Feb 3 '13 at 21:02