Introduction – Getting Started
It is very understandable that in the software industry, we need to run many test assertions to ensure the product has met the customer’s expectation, before we deliver it to him.
Test Assertion – One of the popular definitions of Test Assertion is, “A test is a condition that must be tested to confirm conformance to a requirement”. This explains simply that a test assertion is – a condition. And from functional test point of view, the conformance to a piece of requirement often needs more than one assertion. A test assertion may include prerequisites which must be true for the test assertion to be valid.
Quality Assurance Service (QAs) needs to work with lots of assertion on a daily basis, either manually or automatically, both depending on the complexity and time. No matter how we run the assertions, there’s one thing that we cannot escape – designing them in advance, according to our requirements. Good assertion is mandatory otherwise we risk gathering wrong/inappropriate information from QA work. This may result in delaying the delivery of software or leave issues uncovered in the product. Not to forget, designing good assertions is also vital.
Writing correct assertions
The most common error in daily testing is we are testing more than what needs to be tested. For a flawless assertion, we should keep in mind, the important principle of writing good assertions – when testing an implementation, the objective is to achieve consistent reproductive results that accurately indicate the conformance of the implementation to the specification. In another words – the test assertion will fail if and only if the tested function is broken. And to achieve this goal, we have to examine the part of the software to test carefully, find out what’s unique about it, and what we need to find out as a sufficient proof of its working.
To be able to write good assertion, we need to know the fundamental checkpoints of the requirement, make sure we go from the correct entry to the point we need to test, we need to find out unique identifiers to avoid confusion of the test result. Also, we need to be stern in not including any kind of implicit business logic that is not involved in the requirement and we already know it clearly that to do good assertion, we might need more than one assertion.
Analysis is plays a vital role for writing good assertion.
Benefits of Assertions
The role of assertions is to identify bugs in a program. Ideally testing of a program will find the bugs in a program even without the aid of assertions. In practice, the major benefit of assertions is to make testing more effective. An assertion that is never executed tells you nothing. An assertion is only useful if the code path containing it is executed. Assuming the code is being properly tested, assertions do several useful things:
i.Detect subtle errors that might otherwise go undetected
ii.Detect errors sooner after they occur than they might otherwise be detected
iii.Make a statement about the effects of the code that is guaranteed to be true
The benefits of (i) are obvious. The benefit of (ii) is not in finding a bug that’s going to be found anyway, but rather in making it possible to find the bug faster. The benefit of (iii) is harder to quantify but there’s no doubt that seeing a function assert that one of its parameters is not null tells a programmer more that the parameter should not be null and much much more than totally undocumented code.
Image Credit hostgator.com
