0

While writing this question I found out that I'm faced with 2 problems: a testing one and a production one but I hope that resolving the situation can solve both issues.

Now the question:

I have a set of data coming from a data base. For one of the data I have different rules depending of the value. To simplify let's I have SubsetA with RuleA and SubsetB with RuleB.

To simplify I have:

Rule(Value) {
 if (Value in [ValueA, ValueB] /*SubsetA */) {
  RuleA();
 }
 else {
  RuleB();
 }
}

I'm writing non regression unit test for Rule and expecting results based on rule A and B calls. Since the set of potential value is limited and small I wanted to test each case and check that for each value either RuleA or RuleB is called accordingly (and does what is expected). However since my data come from a database a new value could appear anyway and will have to be tested for either Rule A, Rule B or even a new Rule C.

C would be the easiest case since I expect a new rule to be match with a new test. A and B are different because a new value in database would not fail any test for now because it would default to rule B.

In the else case directing to rule B should I define the complementary set of value (SubsetB) of the if case and define a new else case generating an error? Is it viable for large set of data? Also it's still not caught by unit test. Doesn't it go against the need to have those value in a database?

0

I think that if you have multiple rules for a set you cannot possibly know about in advance, I suggest two possibilities:

If you see that the code will grow to the point where you will need to handle more than say 4/5 rules, not only it becomes impractical to unit test such code, but, more importantly, it will become harder to maintain and be error-prone to work, even with the production code.

So, if you feel that this rule set will keep growing too much, I think the best approach will be to modularize and refactor the code as much as possible to encapsulate individual rules so that they can also be more easily unit tested.

As new rules are added, coverage can be increased as seen fit, and then all will be covered.

If the design allows it, writing a common interface to abstract over the rules also seems like a good idea, and essentially, you get the "expansion" of your rule set covered for free as long as the new rules adhere to a certain proxy/interface.

Then you test the proxy, and you test all at once

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.