Mocking API Responses with Puppeteer Request Interception in Automated Tests
Learn how to mock a specific API call in Puppeteer using request interception to achieve deterministic UI tests without changing the backend.
Loading…
ReadMeFeed / Community knowledge
#mocking
Real questions. Useful conversations. Find the people who know your stack.
nodejs
puppeteerMocking the Network in Puppeteer: Deterministic Tests Without a Backend
Flaky staging APIs make flaky UI tests. Puppeteer's request interception lets you mock, block, or fail HTTP traffic from inside your test process — no backend required.
Isolating Dependencies in Jasmine: Using Spies to Avoid Real Network Calls
Learn how to use Jasmine spies to isolate units under test, mock HTTP dependencies, and verify function calls without relying on live network requests.
Solving the 'Cannot Access Before Initialization' Error in Vitest Mocks
Vitest hoists vi.mock calls, which can cause 'cannot access before initialization' errors. Learn how to use vi.hoisted to safely define mock data and functions.
Mocking External APIs in Karate Tests with WireMock: A Practical Guide
Learn how to use Karate’s built‑in WireMock server to stub external APIs, eliminate flaky tests, and keep your API test suite fast and reliable.
karatelabsChoosing Between jest.fn() and jest.spyOn() for Dependency Isolation
Stop fighting leaky tests. Learn when to use jest.fn() for standalone mocks versus jest.spyOn() for tracking existing methods to create isolated, deterministic unit tests.
jest"authentication‑required error" in racket/db's connect
Goal Determine whether Racket's testing ecosystem should supply a built‑in mock connection for racket/db 's connect procedure so that integration tests can run without real database credentials. Constraints and uncertainty The connect function raises an authentication‑required error when username or password are omitted, as documented in racket/db . Teams cu
racketDropwizard integration tests: choosing an external-service mocking strategy that guarantees no production credential leakage
Context DropwizardAppRule starts the full application lifecycle for integration tests, loading a test-specific YAML configuration that can override production values through environment variables or system properties. The framework does not prescribe a single approach for mocking external HTTP services, databases, or message brokers, leaving teams to decide
dropwizardShould a mocked m.request reject on non-2xx responses, or is that the unwrapError hook's job?
I'm writing integration tests for a Mithril component that fetches JSON via m.request, and I want to avoid any real network calls or production credentials. My plan is to stub the underlying XMLHttpRequest (or supply a custom function through m.request's config) so the test resolves with a canned payload. The part I can't settle is error handling. When my mo