About Lazy Validation

Lazy validation is a validation method to perform better validation with less effort.

How it works

Lazy validation only validates data that is readily available as parameters or immediate results of the tested action and by relying on the model-based test engine to make sure that all other appropriate validations (that is, validation of side-effects) occur later. Lazy validation is related to state-transition testing and Model-Based Testing and works by letting the model-based engine pass stateful objects around between tests of the different actions in the system to ensure that eventually all possible validations have occurred.

To understand lazy validation, imagine a simple CRUD (Create, Read, Update and Delete) system such as a database and consider how to validate deletion. Assume there is one generic test method for each of the Create, Read, Update and Delete operations, that each of these tests take an object as parameter and that this object is annotated with a state factor telling what state the object is expected to be in. Finally, the delete operation itself reports how many objects it deleted. The validation in the test of the Delete operation simply matches the expected state of the object (object exists or does not exist) and the result of the delete operation (zero or one objects deleted). Note that Parameterized Validation is an alternative to program logic to determine expected results.

While this validation may catch basic errors it does not check that the object was actually deleted from the system – only that the delete operation reported the correct number. It is necessary to do more checks but the point with lazy validation is to do these checks in the validation of Create, Read and Update and not as part of the test of Delete. This assumes of course that there will be a test of Create, Read and Update against deleted objects.

The benefit of lazy validation is that it simplifies validation while at the same time making it stronger: For example, the obvious additional validation of a Delete operation is a subsequent Read, but Create, Update and Delete are also affected. With lazy validation there is better assurance that Create, Update and Delete are applied to deleted objects (the choice is made in the Combinatorial Test design). A second benefit of lazy validation is that it is easier to create thorough validations (e.g. checking that all members of the object have the expected values on a Read), because incomplete validations stick out more clearly when all validations work on local data.

Lazy validation decouples actions from the validation of side-effects so if a side-effect fails to validate it is necessary to inspect the history of the involved data. QS contains powerful facilities to assist this inspection.