Jump to content

Test stub

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Licriss (talk | contribs) at 04:44, 10 September 2023 (Removed uncommon terminology from first paragraph that was repeating information). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In software testing, test stubs are programs that simulate the behaviours of software components (or modules) that a module undergoing tests depends on. Test stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.[1]

Example

Consider a computer program that queries a database to obtain the sum price total of all products stored in the database. In this example, the query is slow and consumes a large number of system resources. This reduces the number of test runs per day. Secondly, tests may include values outside those currently in the database. The method (or call) used to perform this is get_total(). For testing purposes, the source code in get_total() can be temporarily replaced with a simple statement that returns a specific value. This would be a test stub.

Several testing frameworks are available, as is software that generates test stubs based on existing source code and testing requirements. Stubs and Drivers are two possible components of a test harness.

Stubs and drivers both are dummy components and are only created for test purposes.

Stubs are used when a component or application is ready but other software that it connects to is not.

For example, in a situation where one has three different modules: Login, Home, User. Suppose login module is ready for test, but the two minor modules Home and User, which are called by Login module are not ready yet for testing. At this time, a piece of dummy code is written, which simulates the called methods of Home and User. These dummy pieces of code are the stubs.

On the other hand, Drivers are the ones, which are the "calling" programs. Drivers are used in bottom up testing approach. Drivers are dummy code, which is used when the sub modules are ready but the main module is still not ready.

Taking the same example as above. Suppose this time, the User and Home modules are ready, but the Login module is not ready to test. Now since Home and User return values from Login module, so a dummy piece of code is written, which simulates the Login module. This dummy code is then called Driver.

See also

References

  1. ^ Fowler, Martin (2007), Mocks Aren't Stubs (Online)