%% Last Updated: - [[2021-04-02]] - [[2020-09-12]] %% A stub is the most basic type of test double that replaces a component using hardcoded responses. While limited in its implementation, a stub can still be useful in that it allows the development or testing of a component to continue without requiring other components outside of scope to be integrated. An example of a stub is something that accepts any request and responds with "HTTP 200 OK". At [[Flood (company)]], the test site https://flooded.io allows any type of request and responds with a HTTP 200, although it only returns the same page each time. Still, this is often enough to prove whether a load testing script is hitting the right endpoint. A stub is that part that replaces a complicated component that is not within scope. It’s a “dumber” version that responds to requests enough to allow you to go on with your load testing without actually requiring that component. Let’s say your application involves customers entering their credit card information upon checkout. That data is then sent to a payment gateway that then sends a message to your app to confirm receipt of payment. Often this payment gateway is outsourced to a third party, but you still want to test that your application saves the order information in your database and shows a “Thank you for your order” message after receiving payment confirmation. It’s often not feasible to include your third party payment provider in your load testing, unless you want to actually be using real credit card numbers. Instead, what you can do is create a stub that will perform this function. You likely don’t need “real” data, so the stub could take the input of a credit card number and send back a “Payment accepted; order number 123456” as the output to your application, allowing your load tests to continue without the payment gateway. ![[Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams#^8a52b8]] [^01] There are much more complex and full-featured enterprise solutions for this in the market, such as [Tricentis Tosca Orchestrated Service Virtualisation (OSV)](https://www.tricentis.com/orchestrated-service-virtualization/). However one good, open-source tool I’ve found that is easy to set up and not too well-known is [Mountebank](http://www.mbtest.org/). If you are willing to put the time into creating a test double, you can drastically reduce the amount of resources you need to set up an environment and isolate components. Reducing variables in your test allows you to more quickly determine where performance bottlenecks lie. ## Related - [[Test doubles]] - [[Test Double Tools]] - [[Service virtualization]] - [[API Load Testing - A Beginner's Guide]] ## References [^01]: [[Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams]]