{
    "content": "<h1>Test Doubles in API Development<\/h1><p>In the field of <a href=\"..\/Software-Testing\/\">Software-Testing<\/a>, a <strong>Test Double<\/strong> is a replacement object used in place of a real dependency during the execution of a test. The term was coined by <a href=\"..\/Gerard-Meszaros\/\">Gerard-Meszaros<\/a> to provide a unified nomenclature for objects that mimic the behavior of production components in controlled environments. This practice is fundamental to <a href=\"..\/Unit-Testing\/\">Unit-Testing<\/a> and <a href=\"..\/Test-Driven-Development\/\">Test-Driven-Development<\/a>, as it allows developers to isolate the <a href=\"..\/System-Under-Test\/\">System-Under-Test<\/a> (SUT) from external factors such as databases, network latency, or third-party <a href=\"..\/Application-Programming-Interface\/\">Application-Programming-Interface<\/a> services.<\/p><h2>Types of Test Doubles<\/h2><p>According to the definitions popularized by <a href=\"..\/Martin-Fowler\/\">Martin-Fowler<\/a>, test doubles are categorized based on their behavior and purpose:<\/p><ul><li><strong>Dummy:<\/strong> Objects passed into methods but never actually accessed; they serve only to satisfy method signatures.<\/li><li><strong>Stub:<\/strong> Provides hardcoded, canned responses to calls made during a test, often used to simulate specific states or error conditions.<\/li><li><strong>Spy:<\/strong> A variation of a stub that records information about how it was called, such as the number of invocations or the arguments passed.<\/li><li><strong>Mock:<\/strong> Objects pre-programmed with expectations that form a specification of the calls they are expected to receive. They verify behavior rather than just state.<\/li><li><strong>Fake:<\/strong> Objects that have a working implementation but are simplified for testing, such as an in-memory database substituted for a persistent <a href=\"..\/SQL\/\">SQL<\/a> database.<\/li><\/ul><p>Implementing test doubles effectively is a core skill in modern <a href=\"..\/Software-Architecture\/\">Software-Architecture<\/a>. It ensures that tests remain deterministic and fast. For a deeper dive into the distinction between state-based and behavior-based verification, refer to the article <a href=\"https:\/\/martinfowler.com\/articles\/mocksArentStubs.html\">Mocks Aren't Stubs<\/a> by Martin Fowler.<\/p><h2>Related Topics<\/h2><ul><li><a href=\"..\/Mocking-Frameworks\/\">Mocking-Frameworks<\/a><\/li><li><a href=\"..\/Integration-Testing\/\">Integration-Testing<\/a><\/li><li><a href=\"..\/Service-Virtualization\/\">Service-Virtualization<\/a><\/li><li><a href=\"..\/Dependency-Injection\/\">Dependency-Injection<\/a><\/li><\/ul>",
    "tags": [
        "testing",
        "software-engineering",
        "unit-testing",
        "mocking",
        "tdd",
        "api-design",
        "stubs",
        "fakes",
        "quality-assurance",
        "architecture"
    ]
}