Method stub

A method stub or simply stub[1] in software development is a piece of code used to stand in for some other programming functionality. A stub may simulate the behavior of existing code (such as a procedure on a remote machine; such methods are often called mocks) or be a temporary substitute for yet-to-be-developed code. Stubs are therefore most useful in porting, distributed computing as well as general software development and testing.

An example of a stub in pseudocode might be as follows:

temperature = ThermometerRead(Outside)
if temperature > 40 then
    print "It is hot!"
end if

function ThermometerRead(Source insideOrOutside)
    return 28
end function

The above pseudocode utilises the function ThermometerRead, which returns a temperature. While ThermometerRead would be intended to read some hardware device, this function currently does not contain the necessary code. So ThermometerRead does not, in essence, simulate any process, yet it does return a legal value, allowing the main program to be at least partially tested. Although it accepts the parameter of type Source, which determines whether inside or outside temperature is needed, it does not use the actual value passed (argument insideOrOutside) by the caller in its logic.

A stub [2] is a routine that doesn't actually do anything other than declaring itself and the parameters it accepts and returning something that is usually the values expected in one of the "happy scenarios" for the caller. Stubs are used commonly as placeholders for implementation of a known interface, where the interface is finalized/known but the implementation is not yet known/finalized. The stub contains just enough code to allow it to be compiled and linked with the rest of the program. In RMI nomenclature, a stub on the client-side communicates with a skeleton on the server-side.[3]

In the context of DOS and Windows, the term stub is also used in a fashion like shim to describe the small areas of interface code left in conventional memory by self-relocating resident drivers which move most of themselves into upper memory, the high memory area, expanded or extended memory as well as similar stubs to allow the relocated code to communicate with real-mode DOS in conjunction with DOS extenders (like DPMI, DPMS, CLOAKING or NIOS).

The small pieces of dummy code branched into—so as to allow a graceful exit when invoking a fat binary in the wrong environment—are also called (code) stubs.