Testing by contract vs Defensive testing

As you know, testing never ends. Either the budget is out or the time runs short. The exhaustive testing is not possible because there is no definite limit of possible input values. Say you are testing an input field where the valid inputs are from 100 to 500. If you use the technique of equivalent class partitioning, you may devise three test cases. One from valid range and two from invalid ranges (one below the valid range and other above the valid range). If you go even further and also applies the techniques of boundary value analysis, you may add up 6 more test cases. Three at the lower boundary and three at the upper boundary.

So far, using equivalent class partitioning and boundary value analysis, you came up with nine test cases and you think these test cases are quite enough to test the given input field. However, as you know, there is no limit of possible inputs. What if the user tries to enter special letters like #$#%. What if the user tries to enter alphabetic letters or simply spaces and so on………..

In such scenario, we need to choose one of the two testing approaches: testing by contract and defensive testing

Testing by Contract.

In testing by contract, we deal with the client that no input that is quite irrational or beyond the context will be entered to test the product. For instance, if there is an alphabetic field to enter name. The user should not try to enter numeric value there and if the user enters such irrational input, the developer will not be blamed for the abnormal behavior of the product.

Defensive Testing

In defensive testing, we act upon the saying that client is always right or client is the king. Even the blunder committed by the client is put on developers shoulder. The product developed by the coder should be error free and robust enough to withstand the quit stupid inputs by the client. In case of such stupid inputs, we can use a systematic exception handling mechanism, which may prompt the message regarding invalid input or take any other reasonable action.

Analogy regarding testing by contract and defensive testing

We can understand the concept by the following photo.

If the bike company has an agreement with the client or end user that no irrational way of testing will be applied. Say, if the user uses lassi (a beverage of yogurt used in india-pakistan) instead of petrol in the bike, the Yamaha company will not be held responsible. Then it is testing by contract. In short, in testing by contract, the parameters of right use of the product are defined and agreed upon in start.

On the other hand, if there is no agreement of right use of the product and the company is held responsible even for improper usage by the user, we use defensive testing. In defensive testing, we keep in mind that the user can enter any stupid input. You know, this universe may have limits, but the stupidity has no limits . In defensive testing, we should apply exception handling. We should make sure that user should not be able to enter stupid inputs. If the user tries to use some beverage instead of petrol, he should not be allowed to do it. In better graphical user interface, the user is always limited to enter the valid inputs only. For example, in the name field, only alphabetic letters are allowed and in credit card field, only numeric inputs are allowed.