Traditionally, from the unit level testing perspective, a software module is defined as” the smallest testable unit of a software application that can be tested separately during system testing”. De facto, there is no generally accepted definition of a software unit and opinions are divided on this point. However, it can be defined as:
- unit is a piece of code that performs one function;
- unit is a programming module, i.e. the smallest compilable piece of a software system;
- unit is a concern from task list of your project (from its manager’s point of view);
- unit is a piece of program code that can fit on one screen or one sheet of paper;
- unit is a separate interface class or a set of unified interface classes.
As a rule, a test unit is accepted as a software component (a compilation unit or entity) in case if the system is developed using a procedural programming language or as a class if the system is developed using an object-oriented language.
For systems written in procedural languages, unit testing is done this way: test driver (dummy module) is created for each unit so that to invoke it and give the same output as that of the original software, and a set of stubs to be used as functions in Top-Down Integration, simulating the called units and take care of control and / or invoking of system or component. Driver and stubs simulate the behavior of software components a module under test is dependent on. They serve as temporary replacement for related modules which have not been developed fully. Object-oriented testing is hard to perform as it encompasses three levels, specifically, unit testing, system testing and subsystem testing. It relates to bundling data and methods in a class. Those, who want to be successful in the undertaking, prefer not to take the risk of doing unknown job but choose to resort to overseas application testing service.
Using smaller split classes and individual methods as test modules is not reasonable for object-oriented systems, since each method needs to be tested in a test environment as complicated as class code already written. In addition, splitting classes into smaller parts violates concept of encapsulation, according to which objects of each class should behave as a unit.
Testing of classes as modules is sometimes called component testing. Such testing refers to testing a test object cab as component in isolation from the rest of the system, without integrating them with other components such as programs, classes, modules, objects and programs. This testing tends to exercise as much of the system as possible.