A stub method is a method that just returns a simple but valid (though not necessarily correct) result.

They are typically made when building the infrastructure and you don’t want to spend time on every method needed right now. Instead you create stubs so everything compiles and your IDE’s auto-complete knows about the methods you are planning to use.

Another place where stubs are used is in mocking when testing, You supply stub methods instead of the normal dependency through dependency injection which return fixed results and then ensure that the code does the right thing with them. This isolates testing to the code you are trying to test and means you don’t need to spin up a database just to run those tests.

Perhaps this is best answered with a concrete example. Let’s consider the case where you’re creating a desktop application. You’ve decided to have a function named createMenubar, createToolbar and createMain so that your application constructor is neat and tidy.

Your main code will look something like this (this example is in python):

class ExampleApp():
    def __init__(self):
        self.createMenubar()
        self.createToolbar()
        self.createMain()

Until you have everything working, your main function will fail, so how can you test your app during development? For example, if you start out working on createMenubar, the initialization will fail after it creates the menubar since you haven’t implemented the toolbar or main area of the GUI.

This is where stubs come in. You can create a function named createToolbar and createMain that satisfy the requirement of the app constructor (namely, that these functions exist), without having to actually implement them. These functions are stubs:

def createToolbar():
    pass

def createMain():
    pass

With those stubs in place you can begin to implement the main program and the menubar, without having to worry about the details of the toolbar or main part of the program. Eventually you’ll move on to the toolbar, and replace the stub with the actual function. And finally, you’ll remove the stub for createMain and give that a real implementation.

Note that stubs don’t necessarily have to do nothing. These stub could, for example, create an empty container widget that the app constructor can lay out. The point is, you create dummy functions or objects that do just enough to let your other code run while you are developing it. Over time you replace the stubs one-by-one until your application is complete.

A “stub” is used in “top down” programming. That’s when you are building your application from the general to the specific. In so doing, you will use “stubs” as “placeholders” for the specific applications that you haven’t had time to build. They often return things like dummy or random values to the more general part of the program. That’s all right, the stub feeds enough of a value to make the more “senior” part of the program work. Until it is time for the stub to be replaced or fitted with its true computation or value.