Test stub

In advanced polymorphism computer science, 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]

Test stubs are mainly used in incremental testing's top-down approach. Stubs are computer programs that act as temporary replacement for a called basin module and give the same output as the actual product or software.

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 types of test harness. Test harnesses are the collection of software and test data which is configured so that one can test a program unit by simulating different set of conditions, while monitoring the behavior and outputs.

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

Stubs are used in top down testing approach, when one has the major module ready to test, but the sub modules are still not ready yet. So in a simple language stubs are "called" programs, which are called in to test the major module's functionality.

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.

gollark: What does `scene_creator` do?
gollark: Also colored things?
gollark: I wish to render "spheres".
gollark: So how do I operate this?
gollark: I got it to do this (PNGized for your viewing convenience).

See also

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


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.