Stub

Podcast 2 — In conversation

Speaker A: The software testing use of stub is one of those cases where a word from ordinary language was borrowed by the programming community and given a precise technical meaning that maps almost perfectly onto the original. A stub in testing is the short, minimal thing that stands in for a real, fully developed thing — just as a pencil stub stands in for a full pencil when the full pencil is no longer available. The stub in testing is not the complete, working component — it is the bare minimum required to allow the rest of the code to function while the real component is not yet ready or is being kept out of the test for isolation purposes. The metaphor is exact.

Speaker B: The ticket stub as a cultural object is more interesting than it first appears. Before the digital age, the stub was both your proof of purchase and your souvenir — the physical evidence that you were at the concert, the match, the film. People kept ticket stubs in shoeboxes and envelopes as records of their experiences in a way that digital confirmation emails and e-tickets do not quite replicate. There is something about the physical stub — the slightly worn paper, the printed date and venue — that carries the sensory memory of the event in a way that a screenshot does not. The stub habit was a form of analogue journaling.

Speaker A: Stub versus stump — what is the distinction?

Speaker B: Both come from the same etymological root — the short remaining piece of something — but they apply to different scales and contexts. A stump is larger and more fixed — a tree stump, a political stump speech from the tradition of campaigning on a tree stump. A stub is smaller, more portable, and more transient — a pencil stub, a ticket stub, a cigarette stub. You might stub your toe on a stump but the word stump does not describe the small painful impact the way stub does. In computing, stub is specific and technical; stump has no equivalent technical use. The distinction is largely one of scale, context, and established usage rather than of fundamental meaning.

Speaker A: What is a common mistake about stubs in software development?

Speaker B: Confusing stubs with mocks, which are related but distinct test doubles. A stub is passive — it returns pre-defined values when called, without verifying how or whether it was called. A mock is active — it records how it was called and can verify that the code under test called it in the expected way. A stub says here is your data; a mock says here is your data and I am also checking that you asked for it correctly. Using a mock when you only need a stub adds unnecessary complexity to a test; failing to use a mock when you need to verify calling behaviour leads to incomplete testing. The distinction matters for writing clean, meaningful tests.

Speaker A: Any close synonyms?

Speaker B: For the physical remaining piece — remnant, nub, end, and butt all cover different specific instances. The butt of a cigarette is its stub. The nub of a pencil is essentially its stub. A remnant is a general term for what remains of something without the specific short-piece quality. In computing, mock, fake, dummy, and spy are all test doubles in the same family as stub, each with a specific pattern. A fake is a working implementation that is simpler than the real thing. A dummy is passed around but not actually used. A spy wraps the real component while recording calls. Stub is the simplest and most commonly used of these, which is why it is the most familiar term.

Podcast 3 — Prompt engineering

Speaker B: Welcome to the workshop. Today we prompt AI using the word stub — building the API stub generators, test double frameworks, service virtualisation tools, placeholder endpoint managers, and mock server systems that create the minimal implementations needed for isolated testing and parallel development.

Speaker A: So stub tells the AI to build the test double and placeholder systems — the API stub generators that create minimal fake endpoints for testing, the service virtualisation tools that stand in for unavailable dependencies, and the code stub generators that create placeholder function implementations for rapid development?

Speaker B: Exactly. It signals test double generation, placeholder implementation, and service virtualisation. Let me start with an API stub generator.

Build an API stub generator: accept an OpenAPI specification and generate a working stub server that responds to every endpoint defined in the spec with realistic-looking fake data matching the response schema. Support configuring specific endpoint responses for different test scenarios — success cases, error cases, and edge cases. Allow setting response delays to simulate network latency. Log all requests received by the stub server for later inspection. Support running multiple stub scenarios simultaneously on different ports for parallel test suites.

Speaker B: API stub generator creates a working fake server from an OpenAPI spec with schema-matching fake data, configurable per-endpoint scenario responses, simulated latency, request logging, and multi-port parallel scenario support — the AI builds the spec parser, the fake data generator, the scenario configurator, the delay simulator, the request logger, and the multi-port server.

Speaker A: Configuring specific endpoint responses for different test scenarios — success cases returning expected data, error cases returning appropriate error codes, edge cases returning boundary values — is what elevates a stub from a passive data returner to a comprehensive test environment: a stub that only returns success cases cannot test how the client code handles failures, and the failure handling is often where the most critical bugs hide.

Speaker B: Scenario-configurable responses as the comprehensive-test-coverage-beyond-happy-path enabler. Now the test double schema.

Design a test stub and mock management schema: a stubs table recording each defined stub with an ID, name, the service it replaces, the OpenAPI spec reference, the current active scenario, and a description. A stub_scenarios table recording each response scenario with a stub ID, scenario name, the endpoint pattern it applies to, the response status code, the response body as JSON, the response delay in milliseconds, and whether the scenario is the default. A stub_requests table recording each request received by a stub server with the stub ID, timestamp, HTTP method, path, request headers as JSON, request body as JSON, and which scenario matched. A stub_coverage_view showing each endpoint in a stub's spec and whether it has at least one custom scenario defined beyond the default.

Speaker B: Test stub schema stores stub definitions with active scenarios, per-stub scenario configurations with response bodies and delays, request log records with matching scenario, and an endpoint coverage view showing which endpoints have custom scenarios defined — the AI builds the four-table schema.

Speaker A: The stub coverage view — showing which endpoints in the spec have custom scenarios defined beyond the default — is the test coverage gap identifier for stub-based testing: an endpoint that only has a default success response has not been configured to test error handling or edge cases, and the coverage view makes these gaps visible so that test writers can add the missing scenarios before coverage is assumed to be complete.

Speaker B: Endpoint scenario coverage view as the stub-based test gap identifier. Next, the stub management interface.

Design a stub server management interface for a development team: display all running stub servers as cards showing the service being stubbed, the active scenario, the port, the request count since start, and uptime. Allow switching the active scenario for any stub from a dropdown without restarting the server. Show a live request log for each stub with the timestamp, method, path, matched scenario, and response code. Support searching and filtering the request log. Allow creating a new scenario by capturing a real request and response to use as a template.

Speaker B: Stub management interface shows service cards with scenario, port, request count, and uptime, supports live scenario switching without restart, shows a filterable live request log per stub, and allows new scenario creation by capturing real requests — the AI builds the card display, the scenario switcher, the live request log, the search and filter, and the capture-to-scenario tool.

Speaker A: Creating a new scenario by capturing a real request and response — recording an actual interaction between the client and the real service and saving it as a stub scenario — is the stub bootstrapping tool that eliminates the need to manually construct realistic test data: the captured real interaction provides a genuine request-response pair that the stub can replay, ensuring the stub data matches the actual format and content of the real service.

Speaker B: Real-interaction capture as the realistic stub scenario bootstrapping tool. On to code stub generation.

Create a code stub generator: accept a function signature — name, parameters with types, return type — and generate a stub implementation in the target programming language. The stub should compile without errors, return a sensible default value for the return type, include a comment marking it as a stub to be implemented, and optionally throw a not-implemented exception. Support TypeScript, Python, Java, and Go. Generate stub implementations for entire interface or class definitions, not just individual functions.

Speaker B: Code stub generator produces compilable stub implementations from function signatures in TypeScript, Python, Java, and Go, with default return values, stub marker comments, and optional not-implemented exceptions, supporting entire interface and class stub generation — the AI builds the signature parser, the language-specific code generator, and the default value selector.

Speaker A: Generating stubs that compile without errors — returning a sensible default value rather than nothing or a syntax error — is the immediate team productivity benefit: a developer who is building module A can generate stubs for all the functions in module B that they depend on and immediately have compilable code that allows them to write and run tests against module A without waiting for module B to be implemented.

Speaker B: Compilable stubs as the parallel development and immediate test writing enabler. Now something whole.

Build a service virtualisation platform: manage a library of stub and mock services for an entire development organisation. Allow teams to register the services they need virtualised, define scenarios for each service, run stub servers on demand, and share scenarios across teams. Track which stubs are most used and identify dependencies between teams through stub usage patterns. Generate a monthly service dependency report showing which services are most frequently stubbed and what that reveals about the architecture's coupling.

Speaker B: Service virtualisation platform manages organisational stub libraries with scenario sharing, on-demand stub server provisioning, cross-team scenario reuse, usage tracking, and monthly dependency reports revealing coupling patterns from stub usage — the AI builds the full service virtualisation management platform.

Speaker A: The monthly service dependency report derived from stub usage — identifying which services are most frequently stubbed out by other teams — reveals the actual coupling in the architecture: the services that every other team stubs to test in isolation are the services that everything depends on, and high stub usage is the proxy metric that identifies architectural bottlenecks and single points of failure before they cause production incidents.

Speaker B: Stub usage frequency as the actual architectural coupling and bottleneck identification proxy metric. Last one — ticket stub tracker.

Write a receipt and transaction stub management system: generate transaction receipt stubs when payments are processed, storing the transaction ID, amount, merchant, timestamp, and status. Allow users to view, search, and export their transaction history. Support marking transactions as disputed. Send a monthly transaction digest email summarising spending by category. Automatically flag unusual transactions — amounts significantly above the user's normal spending pattern for a category — for user review.

Speaker B: Transaction stub manager generates receipt records on payment, supports history viewing, search, export, and dispute marking, sends monthly category spending digests, and flags unusual transactions against the user's category spending baseline — the AI builds the receipt generator, the history viewer, the digest emailer, and the anomaly flagger.

Speaker A: Flagging transactions significantly above the user's normal spending pattern for a category — rather than applying a fixed absolute amount threshold — personalises the anomaly detection to each user's actual habits: a transaction of five hundred pounds that would be flagged for a user who normally spends fifty pounds per transaction in a category is entirely normal for a user who regularly spends several hundred, and the pattern-based flag catches the former without constantly alarming the latter.

Speaker B: That is the goal — one blunt word, better-structured testing and receipt systems. Keep it in your kit.