September 2026 Summaries

Proxymock is presented as a tool for capturing an application’s real HTTP and MySQL traffic and reusing one recording for mocked application checks, MySQL upgrade regression tests, and concurrent database load tests. The guide focuses on moving from MySQL 8.0, which entered Oracle Sustaining Support in April 2026, to MySQL 8.4 LTS, highlighting compatibility risks such as authentication defaults, reserved keywords, removed statements, and changed InnoDB behavior. Using a Docker-based Go users-and-orders demo, it records prepared statements, transactions, and their parameters, then first verifies that the application can run against mocked MySQL traffic without a database. It next reverses the replay direction so captured outbound MySQL statements test a real database, demonstrating a clean replay against MySQL 8.4 and a failed replay after a referenced column is renamed, with MySQL error details identifying the incompatibility. The same recording can be load tested through multiple persistent MySQL sessions, where replay-specific duplicate values can be regenerated with extractors and real concurrency problems, such as checkout deadlocks, can expose needed application changes. The guide also covers reviewing saved runs in the local web viewer or Speedscale dashboard, credential and TLS handling, and limitations including the need for disposable databases, state alignment with the original recording, and incomplete support for some MySQL protocol features.

Rising gasoline prices and evidence of fewer but larger online purchases may increase pressure on retailer checkout systems during the 2026 holiday season, making realistic load testing important before Black Friday on November 27. The piece cites impact.com data showing a 7% decline in transactions and a 16% rise in average order value among 2,319 North American brands, while 2025 holiday online spending reached $257.8 billion and involved sustained high-demand days rather than a single peak. It argues that checkout tests should reflect complex carts, promotions, split shipments, financing options, and dependencies such as payment processors, buy-now-pay-later providers, fraud tools, tax services, and shipping APIs, since outages and latency can affect revenue even when systems remain technically available. Observability and code freezes can reduce operational risk but cannot prove that new releases will perform under representative peak traffic or partner failures. The proposed approach is to capture and replay production API traffic in isolated environments, supplement it with new promotional scenarios, test sustained peak loads, mock external services, and deliberately introduce delays and failures to validate retries, timeouts, alternate payment options, and duplicate-order protections. Speedscale is presented as a tool for conducting these traffic replay, dependency mocking, and API chaos tests, alongside a nine-week preparation timeline leading to holiday deployment decisions.

Proxymock can capture an application’s real PostgreSQL traffic—including prepared statements, parameters, reads, and writes—and reuse one recording for mocked app checks, database migration regression tests, and concurrent load testing. By applying a tests filter that promotes recorded outbound PostgreSQL calls into tests, users can replay queries against a new schema or PostgreSQL version, identify statements whose results differ from the original recording, preserve SQL errors for diagnosis, and enforce failure thresholds in CI. Load tests can run the same queries through multiple database sessions while reporting per-query throughput, latency percentiles, and failure rates, offering more context than a single statements-per-second figure. The tool supports CLI, AI assistant, web, and Speedscale dashboard workflows, validates database credentials before replay, and can expose replay sessions in PostgreSQL monitoring views. Because replays execute real writes, they should target disposable databases, and users should account for recorded row IDs, repeated inserts, statement-by-statement transaction replay, and current limitations involving COPY operations and function calls.

Speedscale introduces group rules for Kubernetes API-traffic data loss prevention (DLP) to address the risks and coordination problems of maintaining one shared redaction policy across multiple teams. The approach combines a small, organization-wide baseline rule for universally sensitive data such as credentials and government identifiers with separately owned, workload-scoped group rules that add redactions for specific namespaces, services, or clusters. Redaction is additive, so group rules cannot weaken the baseline or affect unrelated teams’ traffic, while the owner field improves accountability and prepares the model for future role-based access controls. Rules can be created, tested against recorded traffic, previewed in their effective combined form, enabled, and deployed through proxymock web or the Speedscale dashboard; administrators should note that saves reload connected forwarders briefly and that rules should be disabled before deletion. Available in Speedscale version 2.5.1022 and later, the feature is intended to let teams independently manage sensitive fields while preserving central protections and safer shared-cluster traffic capture.

Traffic replay can help AI coding agents validate changes against recorded behavior rather than relying solely on tests whose expectations may reflect the same assumptions used to create the code. Using Cursor, proxymock, and a local Go example from the mock-lab repository, the workflow records requests to a working application and its downstream dependencies before changes are made, then replays those requests against an updated app with recorded dependency responses. Agents can compare status codes and response bodies, identify mismatches, distinguish configuration issues from regressions, and rerun the unchanged baseline after fixes. In the demonstration, two of eight requests initially failed because recorded authentication and order identifiers were stale; after replay configuration propagated fresh values, all requests matched. Developers can inspect detailed replay results in proxymock’s web viewer rather than relying only on an agent’s report, while retaining unit tests and adding separate tests for new or intentionally changed behavior.

Investigating eBPF-based plaintext capture for rustls revealed that correctly captured HTTP data could still be attributed to the wrong TCP connection because rustls deliberately separates TLS state from transport I/O and Tokio tasks share and migrate across worker threads. Thread-local tracking of the most recently read socket therefore produced convincing but incorrect associations when pooled connections or multiple GraphQL subgraphs were active, while an attempted Tokio task-ID probe failed because the relevant generic async code paths had inlined the target function, leaving only unused-for-this-workload out-of-line symbols. Further debugging showed that a kernel probe’s early return for TLS flows had prevented the socket-to-thread correlation map from being populated at all, demonstrating the value of counters for producer updates, lookups, and bindings rather than relying on payload dumps. The eventual approach recorded TCP flow activity after successful reads and bound that flow to rustls’s ConnectionCore during tokio-rustls’s immediate read-and-process-packets sequence, when the thread-local socket evidence was still fresh; subsequent plaintext operations used the durable connection-to-flow binding. In testing against Apollo Router with two TLS backend services, correct plaintext-chunk attribution improved from 10 of 36 chunks to 94 of 96, with the remaining misses explained by connections established before probes attached. The investigation emphasizes testing with multiple connections, verifying that instrumentation points execute at runtime, separating cache liveness from correctness, and recognizing that sans-io TLS libraries do not inherently expose socket identities.

OpenTelemetry’s widespread adoption as an observability standard has also encouraged its use for purposes beyond traditional traces, metrics, and logs, including general data pipelines, infrastructure inventory, routing and experimentation, billing metering, and storing application payloads. Its Collector is increasingly used to transform and route security, audit, and compliance data, but its backpressure behavior can drop records, making external durable queues necessary for data requiring completeness. Entity events can support live infrastructure inventories, although at-least-once delivery introduces duplicates and ordering challenges, while baggage can propagate tenant, experiment, or routing information but has size limits, may silently discard entries, and can expose data across trust boundaries. Usage metrics may support billing workflows, but duplicate delivery requires separately implemented idempotency, reconciliation, and auditing. Adding request bodies, SQL, or generative AI prompts to spans is convenient but can exceed attribute limits, create high-cardinality costs, and transmit sensitive information to telemetry systems. The text recommends assessing whether data can tolerate loss, has bounded cardinality, and crosses trust boundaries before sending it through OpenTelemetry, while using dedicated traffic capture tools when full request and response replay is needed.

proxymock is presented as a tool for reducing the maintenance burden of handwritten network mocks by recording real HTTP traffic, using inbound requests as replayable tests, and serving outbound interactions as recorded dependency responses. In the Speedscale mock-lab example, an application’s real routing, client construction, parsing, error handling, and state run normally while proxymock captures or replays traffic at the network boundary across several programming languages. Recorded request-response pairs can provide stub-like responses, wire-level spying, mock-server enforcement, deterministic fault injection, and regression fixtures, enabling tests for failures such as 503 responses, latency, corrupted bodies, stalled connections, and dropped responses. The walkthrough emphasizes asserting customer-visible behavior rather than every implementation detail, while using interaction assertions only when an external action itself matters. proxymock does not replace unit-level stubs or stateful fakes, which remain better suited to isolated decision logic and in-memory state, but it tests risks that those doubles cannot, including actual HTTP behavior and client parsing. Edited recordings can simulate and validate responses to contract drift through OpenAPI checks, although fresh traffic or scheduled live checks are still necessary to determine whether an upstream dependency has changed in reality.

This ten-part series explains mocking as a way to give tests control over dependencies such as APIs, databases, clocks, queues, and services that are slow, unavailable, costly, non-deterministic, or unfinished. Using a package-notification example, it shows that a test cannot reliably cause a real carrier API to report a delayed shipment, whereas a stand-in can produce that condition on demand and verify the application’s resulting decision. The series emphasizes that mocks require a design seam where a dependency can be replaced and that they trade realism for control: a mocked test can prove behavior given a specified response but cannot validate the real service’s availability, protocol, configuration, or contract. It cautions against excessive mocking because stand-ins can preserve outdated assumptions while real integrations change, leaving tests green despite broken production behavior. Across examples in Java, Node.js, Go, and Python, the posts cover creating useful mocks, simulating failures, testing side effects with spies, avoiding brittle interaction-based tests, distinguishing types of test doubles, testing real clients against fake HTTP servers, detecting contract drift, and selecting appropriate fidelity as systems grow.

The fifth post in a ten-part testing series examines how exhaustive spy-based interaction assertions can over-specify implementation details rather than protect observable behavior. Using Java, Node.js, Go, and Python examples of a package notifier that retries an unavailable carrier service, it shows how tests that record and assert every carrier call and delay fail when the retry backoff changes from fixed to exponential, despite customers seeing the same outcome: no notification is sent and the carrier failure reaches the caller. The post distinguishes internal choreography, such as retry timing and call order, from externally meaningful outcomes, warning that strict mocks and full interaction transcripts make refactoring unnecessarily costly. It recommends retaining interaction assertions when the interaction itself is observable behavior, such as verifying that no customer message was sent, while moving genuinely important internal requirements, such as rate-limit-sensitive backoff rules, into separate, explicitly named tests.

Earlier tests for a package notifier replaced the carrier lookup function entirely, effectively testing decision logic while leaving URL construction, headers, status handling, and JSON parsing untested. The post advocates adding small wire-level tests using a locally controlled fake HTTP server, allowing the real client to send requests and parse responses while tests verify paths, API-key and Accept headers, successful decoding of all known shipment states, 503 error handling, and malformed JSON behavior. It compares available server tools in Go, Java, Node.js, and Python, noting that Java and Node require test dependencies while Go and Python can use standard libraries, and highlights HTTP header case normalization in Python. Function stubs and fake servers serve complementary purposes: stubs efficiently test notifier behavior at an application seam, while fake-server tests validate the client’s protocol implementation between that seam and the network socket. However, because the fake server returns responses written by the test authors, these tests cannot confirm that the real carrier API continues to use the expected contract, such as field names or response structures.

The series distinguishes five test-double roles based on behavior rather than mocking-library terminology: stubs provide predetermined answers, spies record side effects for later assertions, fakes are lightweight working implementations with state, dummies merely satisfy unused parameters, and mocks contain expectations that fail tests themselves. It introduces an in-memory recorder fake for a package notifier, allowing tests to verify that repeated notification attempts send only one delayed-package message because later calls can observe state written by earlier ones. The discussion argues that fakes are appropriate when interactions depend on prior writes, while canned stubs cannot model changing state, and cautions that fakes must preserve important production behavior such as retaining the first recorded message. It also contrasts spies, where tests interpret recorded calls, with mocks, which enforce behavioral expectations internally, recommending mocks sparingly for simple collaborators. Although the fake verifies application-level idempotency, it does not reproduce database constraints, transactions, concurrency, or HTTP behavior, which require other forms of testing.

A carrier API field rename from `status` to `shipmentStatus` can silently break a shipment notifier when tests rely entirely on stubs, fixtures, and fake servers that preserve outdated assumptions while production responses change. Capturing fixtures from real API responses improves realism by documenting a response that was valid at a specific time and environment, but fixtures alone cannot detect later drift. Clients should explicitly reject missing required fields rather than treating absent values as empty or negative results, and should classify such failures as contract errors rather than transient outages that merit retries. Scheduled, opt-in contract tests using real credentials and live API calls can verify that required response fields remain available, while comparing live response shapes against recorded fixtures can reveal renamed, removed, or newly added fields beyond those the application currently reads. Fast mocked tests remain valuable for broad, repeatable scenario coverage, but live contract tests provide the connection to external reality needed to prevent silent incompatibilities, although they still cannot detect semantic changes in fields whose names remain unchanged.

Testing external API-dependent code should begin by identifying a scenario the test cannot control, then introducing a seam that allows the dependency to be replaced rather than immediately adopting a mocking framework. Using a package notifier that sends a message only when a carrier reports a delayed shipment, the material shows how direct HTTP calls prevent deterministic tests because the carrier controls the package status. Refactoring the notifier to accept a status-lookup function or interface separates its decision logic from HTTP communication, enabling tests in Java, Node.js, Go, and Python to supply simple lambdas that deliberately return “delayed” or “delivered.” This approach demonstrates dependency injection without a framework and produces fast, network-free tests that verify the notifier’s behavior. It also emphasizes that mocked tests trade real-world validation for control, so they do not confirm carrier connectivity, API paths, headers, JSON formats, or production configuration; those integration concerns require separate tests, such as ones using a fake HTTP server.

Test substitutes should be chosen according to the specific risk a test needs to address, balancing fidelity against speed, setup effort, and the danger of silent drift rather than adopting more elaborate tooling by default. The progression ranges from fast hand-written function stubs for decision logic, through in-memory fakes and in-process or standalone fake servers for state and protocol behavior, to recorded traffic and disposable real dependencies for increasingly realistic validation. As systems expand across many endpoints and teams, independently maintained stubs and aging fixtures can become untrustworthy, making shared mocks, captured traffic, contract tests, or real dependencies appropriate when concrete compatibility risks arise. The central recommendation is to begin with the smallest substitute that answers the test’s question—often a function stub—and move up only when an identified gap becomes material, while using the real dependency directly when it is fast, deterministic, and accessible.

When a notifier changes from returning a message to sending it through an external email or SMS service, unit tests can no longer rely on return values and should instead inject a sender spy that records messages for later inspection. The text distinguishes stubs, which provide required inputs such as shipment status, from spies, which capture outputs such as requests to send notifications, while noting that tests commonly use both. It advises against asserting log output or calling real provider sandboxes in unit tests because those approaches create brittle contracts or introduce external dependencies. Tests should compare the spy’s complete list of sent messages to verify both exact content and number of sends, including confirming that no message is sent for delivered, unknown, or failed shipment-status lookups. Although a spy verifies the notifier’s decision to request a send, it cannot establish that an external provider delivered, rendered, or accepted the message, which requires integration testing at another layer.

Part three of a ten-part series explains how dependency seams make failure and retry behavior testable in a package notifier without relying on a real carrier service or real time delays. By injecting both a shipment-status lookup and a sleep function, tests can simulate carrier refusals, timeouts, unknown status values, temporary recovery, and permanent failure while verifying retry counts and backoff calls quickly. The examples in Java, Node.js, Go, and Python emphasize using named errors rather than message strings and treating unknown statuses as an explicit product decision rather than an accidental crash. These unit tests establish that failures surface appropriately, recoverable errors trigger retries, and retry budgets eventually stop, but they do not validate whether simulated failures accurately match real carrier behavior or whether the configured retry policy is appropriate. Future installments will test a real HTTP client against a fake server and address the risk that invented test failures diverge from production conditions.