White-Box Unit testing - A Bottom-Up Approach of Software Testing

White-Box Unit testing – A Bottom-Up Approach of Software Testing

Posted in: White Box Testing

White-Box Unit testing – A Bottom-Up Approach of Software Testing

Unlike black box software testing, white box unit testing is a strategy that requires knowledge of the internal structure of a program to design test cases. Based on this structure, white box software testing also called glass box testing, exercises statements, branches, paths, loops, and data flows in order to expose construction defects and security vulnerabilities.

Because of the level of detail required to implement and verify its results, traditionally this type of testing has been performed for relatively small code elements. However, with the use of the modern technology facilitating automatic generation of test cases, white box unit testing can now span multiple classes and even sub-modules.

White box unit testing is one of the recommended best practices used during code construction. It should be conducted as soon as units are implemented and before the code is checked into the shared source control system.

Why

do we carry out white-box unit testing?
It is performed as one of the very first software testing activities, white box unit testing provides immediate feedback to the developers about code quality. It primarily has two objectives like:

1) Exercise a wide number and variety of branches and paths (including perhaps unintentional paths)

2) Uncover construction defects resulting in faults such as runtime exceptions or invalid memory accesses.

By identifying and correcting these faults early in development, defect propagation to other parts of the code is minimized, and it is ascertained that the code can process a wide variety of permissible inputs without faulty execution, exposing security vulnerabilities, or behaving unpredictably.

Code construction robustness becomes increasingly important with new technologies like web services, where system interfaces are exposed to the outside world. If code in these systems is not tested properly, unpredictable behavior not only can lead to functionality and performance problems, but also can provide intruders with pipelines to enter and manipulate the system.

Who should ideally do the white-box unit testing?
Ideally developers are best suited for conducting white box unit testing.

What is the methodology of white-box unit testing?
White box unit testing starts at the function, method, and basic class level and progresses through complex classes and sometimes sub-modules. However, not all methods and classes require separate unit tests. If the code is not very complex, it is much more efficient to generate unit tests for a set of interacting classes instead of each individual class.

White box software testing presents several “what-if?” questions that determine whether the application continues to behave appropriately under unusual or exceptional conditions. Its success depends upon the developer�s ability to create a set of test inputs that is wide and varied enough to cover the unit�s branches and paths as fully as possible and perhaps expose unexpected behaviors. However, creating such a set of tests is a challenge since the number of possible program paths could be prohibitively large, and testing all paths is often not only impractical but simply not feasible. A great software testing expert GJ. Myers had quoted that even a small program with just 20 lines of code can have 100 trillion paths.

For white box software testing, the focus should be on exercising branches and statements, rather than paths. Additionally, variables used in calculations and predicates should be tested, as well as possible outcomes of Boolean expressions. All unit tests must be repeatable. Once executed, their expected results are manually compared with actual results, as described in following picture. The tests are marked as passed only if these results match.

unit's white box testing results

Once the unit’s white box testing results meet their test progression criteria, such as 90% statement coverage, and all white box unit tests pass, the unit can be checked into the source control system. At this time, the unit’s white box tests are converted into black box tests.

Developers usually perform the following tasks while doing white box software testing:

1) Verifying results of white box tests

2) Selecting a subset of these tests that focuses on the unit�s functional requirements

3) Adding other tests that verify unit functionality

4) Marking all verified tests as black box tests

Thus, the end product of white box testing is a set of test cases that capture the unit�s intended behavior.

If an expanded infrastructure is used for the project, these verified test cases should be then added to the automated testing system. Additionally, these test cases can be used as a baseline to detect changes introduced by code modifications, and once the code development stabilizes in the current iteration, they should be included in the automated regression testing system.

What do we measure during white-box unit testing?
White box software testing measures belong to the broad category of code coverage analysis. In coverage analysis, test adequacy indicators such as coverage criteria are used to define test-finishing rules. Test finishing rules answer the fundamental question, “How much testing is enough?” For example, if a goal is to assure that all statements in the unit are executed at least once, the criterion is 100% statement coverage. Similarly, a requirement might be to achieve 100% condition decision coverage, in which all possible outcomes of every condition are tested. Other important measures in this category include variable c-uses, which are uses of variables within computational expressions, and variable p-uses, which are uses of variables within conditional expression predicates. For each of these tests, the expected and the actual results are compared to determine whether the test has passed or failed.

Automation of white-box unit testing process:
Unit testing tools can automatically generate a wide variety of inputs designed to thoroughly exercise the unit, execute test cases with those inputs, and then report results including the exceptions that occur during test case execution. Automation of both test generation and execution not only improves the effectiveness of the testing process but is also essential in preventing test design and implementation and test harness defects.

Generally 60 to 70% statement coverage can be achieved by out-of-the-box, automatically generated test cases. Test case execution can be performed interactively (by the developer while working on code in the IDE), or automatically (in batch mode, as part of the automated software testing suite). Once verified and marked as black box tests, unit tests should be added to the test suite and integrated with the build system.

Many more Articles & Tutorials on White Box Testing

0 0 votes

Article Rating