Automated React Native tests [@CharlieHelps]

[jamonholmgren]

Research and enumerate the most popular and technically sound testing setups for react native applications. then analyze our repository and determine which setup will be most effective.

If you determine none are effective, do more research to discover a setup that will better approximate sound React Native tests in this repository. We need unit and integration testing for the code here.

Once a determination is made, create a plan for implementing a testing strategy in the repository and report it in this issue.

[charliecreates]

Expand this to see my work.

• Reviewed the apisauce codebase structure and usage patterns (core in src/apisauce.js, tests in __tests__, usage of axios and adapters) to understand current test surface and how it translates to React Native environments.
• Researched modern React Native testing stacks (Jest + React Native Testing Library, Detox, Maestro, and MSW/Mock Service Worker patterns) and compared them against apisauce’s needs, focusing on unit vs. integration boundaries and network mocking.
• Validated that apisauce itself is a framework-agnostic HTTP wrapper and that React Native specifics mostly come from axios adapter behavior, meaning tests should target request/response behavior and error handling rather than platform UI.
• Evaluated existing Jest setup options (including jest-expo, react-native Jest presets, and plain Jest + @react-native-community/cli) and narrowed down to a Jest-based approach with MSW or custom mocks for HTTP as the most fitting for this repo.
• Drafted a testing strategy outline emphasizing: Jest as the test runner, focused unit tests around core functions like create, convertResponse, and transformers, plus integration-style tests that simulate real network responses in a React Native-like environment.
• Started writing a phased implementation plan for #338 that covers tooling selection, configuration updates (Jest config, Babel/TypeScript alignment), test structure conventions, and example test cases to bootstrap adoption.

[charliecreates]

Here’s a concrete proposal for automated React Native testing for apisauce, plus the research behind it.

TL;DR:
For React Native, the most practical and “sound” setup for this repo is:

• Unit-level coverage: keep existing Node/Ava tests for core behavior and add a small React Native example app that uses Jest (React Native preset) to sanity-check that apisauce works from a RN bundle.
• Integration/E2E coverage: add Maestro flows that drive that RN app on a simulator/emulator and exercise real network calls through apisauce.

This aligns with current React Native and Infinite Red best practices (Jest for unit, Maestro for E2E), without forcing a migration of the core test suite. (reactnative.dev)

---

High-level recommendation for this repo

1. Do not replace the existing tests.

   • The current Ava + Node HTTP server tests already give strong coverage of the core behavior (status mapping, problem codes, transforms, headers, etc.).
   • We’ll keep these as the “authoritative” unit/integration tests for the library logic.

2. Add a minimal React Native example app under examples/ that uses apisauce.

   • Scaffold with Ignite or the React Native CLI (Ignite is probably nicer since Infinite Red maintains it and it already includes Jest + RN Testing Library + Maestro wiring). (docs.infinite.red)
   • Link it to the local apisauce package (e.g., file:.. dependency) so CI can test against the current branch, not the last published version.

3. Inside that RN app, use Jest for “unit-style” tests of an apisauce-based service.

   • Jest is the default RN test runner and works well for small, fast unit tests. (reactnative.dev)
   • These tests can live entirely inside the example app and just verify:
     • The app can import and bundle apisauce in a RN environment.
     • A simple “service” function using apisauce returns the expected ok, data, problem, etc. (these can be mocked or run against a simple server).

4. Use Maestro for RN-level integration/E2E tests.

   • Maestro is now the preferred E2E stack in Ignite (replacing Detox) and is designed to run flows on iOS and Android with simple YAML files; this is already part of Infinite Red’s recommended stack. (maestro.dev)
   • For this repo, Maestro flows would:
     • Launch the RN example app on a simulator.
     • Navigate to a test screen.
     • Trigger apisauce calls to a local test server.
     • Assert on rendered UI that reflects status, ok, and problem from apisauce.

5. Run RN tests in CI as a separate job.

   • Keep the main npm test / Ava job as-is.
   • Add:
     • A Jest job scoped to the RN example app.
     • A Maestro job that runs on macos-latest (iOS simulator) and/or Linux (Android emulator), using only the open-source Maestro CLI (no requirement to pay for Maestro Cloud). (maestro.dev)

---

Research: common React Native testing setups

1. Jest + React Native Testing Library (RNTL)

• What it is:
  • Jest as the test runner (bundled by default with new RN apps via react-native Jest preset). (reactnative.dev)
  • @testing-library/react-native for component-level tests, mirroring the JS DOM Testing Library ergonomics. (docs.infinite.red)
• Strengths:
  • Standard across the RN ecosystem and well supported in the official docs.
  • Great for “unit” and “integration” tests at the JavaScript/component level (no emulator required).
  • Already the default stack in Ignite (Infinite Red’s RN boilerplate). (docs.infinite.red)
• Weaknesses / Limitations:
  • Runs in a Node test environment, not on an actual device; doesn’t exercise the RN native networking stack or app lifecycle.
  • For apisauce, it will validate JS behavior and bundling, but not subtle differences in the RN Axios adapter.

2. Jest + Detox for E2E (historical default)

• What it is:
  • Detox is a gray-box mobile E2E framework that runs the actual app on a device/simulator and drives it via JS tests (often via Jest). (github.com)
• Strengths:
  • Deep integration with RN, including synchronization with the JS/native event loops, to reduce flakiness. (github.com)
  • Long track record in RN; battle-tested and well documented.
• Weaknesses / Current trends:
  • Setup and maintenance can be complex; changes to RN, native deps, or CI images can break the setup. (wix.github.io)
  • Many teams (including some in the RN community) are experimenting with simpler black-box tools like Maestro, especially for new projects. (docs.infinite.red)

3. Jest + Maestro for E2E (modern / simple black-box)

• What it is:
  • Maestro is a black-box UI testing framework that drives iOS/Android/Web apps via YAML “flows” and a CLI or cloud runner. It supports React Native explicitly. (maestro.dev)
• Strengths:
  • Very simple to get started; flows are high-level and readable.
  • Cross-platform (iOS and Android) and framework-agnostic; works for RN and non-RN apps. (maestro.dev)
  • Infinite Red’s Ignite boilerplate now ships with Maestro as the default E2E solution (replacing Detox), which is a strong signal of its viability in RN production apps. (docs.infinite.red)
  • Free to run locally with the CLI; Maestro Cloud is optional for hosted device farms. (maestro.dev)
• Weaknesses:
  • Relatively newer than Detox; some advanced scenarios may require workarounds or JS snippets.
  • Being black-box, it has less direct introspection into RN internals than Detox’s gray-box model.

4. Jest + Appium (framework-agnostic mobile E2E)

• What it is:
  • Appium is a WebDriver-based mobile automation framework used for native, hybrid, and mobile web apps.
• Strengths:
  • Extremely flexible and technology-agnostic.
  • Good if you need the same E2E tool across many non-RN apps.
• Weaknesses:
  • Heavier setup and more verbose tests than Detox/Maestro; usually overkill for a small RN library like apisauce.
  • Not particularly aligned with Infinite Red’s typical RN stacks.

Summary:
For apps, the most common and “sound” modern setup is:

• Unit / component / small integration: Jest + React Native Testing Library.
• E2E / full integration: Detox or Maestro, with a trend toward Maestro in newer Ignite-based projects. (docs.infinite.red)

For this library (no UI, just networking), we mostly care about:

• JS-level behavior (already covered by Ava).
• Ensuring that behavior holds when the library is imported and executed in a real RN app, on real devices/simulators.

---

Repository-specific analysis

• apisauce is:
  • A single-package JS/TS HTTP client wrapper around axios (lib/apisauce.ts).
  • Shipping primarily as a Node/CommonJS library with a hand-maintained .d.ts.
  • Already well-covered by serial Ava tests that spin up a Node HTTP server and exercise all the main behaviors (status codes, errors, timeouts, transforms, headers, monitors, etc.).
• There is currently:
  • No React Native app in the repo.
  • No Jest config.
  • No mobile E2E tooling.
• React Native–specific failure modes for a library like this tend to be:
  • Differences in axios adapters (XHR in RN vs HTTP in Node) and how errors/timeouts surface.
  • Packaging/bundling issues (e.g., wrong main/types, missing polyfills).
  • Environmental differences (network stack, cookies, etc.).

Given that:

• Replacing Ava with Jest across the entire library would be a large, out-of-scope refactor.
• Adding Detox just for a small test app feels heavier and less aligned with Infinite Red’s current RN practice.
• Adding one RN example app plus Jest + Maestro is enough to:
  • Validate that apisauce works in practice inside a RN app.
  • Give us room to add targeted regression tests when RN-specific bugs are reported.

So the most effective setup for this repo is:

Keep Ava for the core library, and add a small RN example app that uses Jest for unit checks and Maestro for RN-level integration/E2E tests involving real network calls.

---

Proposed implementation plan

I’d approach this in phases so we can stop at each step if the value/cost trade-off doesn’t pencil out.

Phase 1 – RN example app + wiring to local apisauce

Goal: Have a minimal RN app in this repo that imports and uses the local apisauce build.

• Create an example app under examples/:
  • Option A (recommended): npx ignite-cli new apisauce-rn-example inside examples/ (using the latest Ignite boilerplate).
  • Option B: npx react-native init ApisauceRnExample and manually add Jest/RTL/Maestro (more work, less aligned with IR tooling).
• Update its package.json to depend on the local library:
  • "apisauce": "file:../.." or similar, depending on final directory structure.
• In the example app, add:
  • A simple ApiTestScreen or service function that:
    • Uses apisauce.create(...) with a configurable base URL.
    • Exposes buttons/actions to hit endpoints like /status/200, /status/404, /timeout, etc.
    • Renders the resulting status, ok, problem, and maybe a snippet of data.
• Add a short section to this repo’s README explaining:
  • Where the RN app lives.
  • How to run it locally (cd examples/apisauce-rn-example && yarn ios / yarn android).
  • That it’s primarily there to support automated RN tests, not as a full-featured demo app.

Deliverable: RN example app with apisauce correctly wired and running manually.

---

Phase 2 – Jest-based RN “unit” tests in the example app

Goal: Fast tests that validate apisauce usage from RN JavaScript without bringing up a simulator.

• Use the existing Jest setup from Ignite (or add Jest with the react-native preset if using plain RN CLI). (jestjs.io)
• Add a small “service” module in the example app, e.g. app/services/apisauceService.ts:
  • Exposes functions like fetchOk(), fetchNotFound(), fetchTimeout().
  • Each function calls apisauce.create(...).get(...) or post(...) and returns the ApiResponse.
• Write Jest tests in the example app’s test/ folder that:
  • Use Jest mocks for the underlying HTTP layer (e.g., mock axios or stub the service to avoid real network).
  • Assert that:
    • We can import apisauce from the local file dependency.
    • The service returns the right shapes for ok, data, problem, and status for common cases.
• Add scripts:
  • In root package.json: "test:rn:unit": "cd examples/apisauce-rn-example && yarn test".
• CI:
  • Add a lightweight GitHub Actions job that:
    • Installs example app deps.
    • Runs npm run test:rn:unit.

Value:
These tests are quick sanity checks that protect against packaging and basic API regressions in a RN-compatible toolchain, with very low ongoing cost.

---

Phase 3 – Maestro-based RN integration/E2E tests

Goal: Exercise apisauce end-to-end inside an actual RN app, running on a simulator/emulator, hitting a real HTTP server (similar to the current Ava setup, but from RN).

• Test server:
  • Reuse as much as possible from test/_server.js in this repo.
  • Either:
    • Run the existing Node test server in a separate process before starting E2E (npm run test-server:rn), or
    • Embed a lightweight copy of the server in the example app repo with a dedicated script.
• App test screen:
  • In the RN example app, refine ApiTestScreen to:
    • Provide buttons like “GET 200”, “GET 404”, “GET 500”, “Timeout”, “No Server”.
    • Display key fields: status, ok, problem, and maybe a truncated data.
    • Use testIDs for buttons and important text elements so Maestro can target them easily. (docs.maestro.dev)
• Maestro setup:
  • Install Maestro CLI as a dev dependency in the example app or at the repo root, following Maestro’s RN docs. (maestro.dev)
  • Create .maestro/ flows in the example app:
    • apisauce-happy-path.yaml:
      • Start app → open ApiTestScreen → tap “GET 200” → assert ok is true and status is 200.
    • apisauce-error-paths.yaml:
      • Test 404/500/connection error flows and assert problem matches expectations (CLIENT_ERROR, SERVER_ERROR, CONNECTION_ERROR, TIMEOUT_ERROR, etc.).
    • apisauce-timeouts.yaml:
      • Hit a /sleep/:ms endpoint and assert problem = TIMEOUT_ERROR at the RN level.
• CI integration:
  • Add a GitHub Actions workflow (likely macos-latest first) that:
    • Installs RN example app deps.
    • Builds the app for iOS simulator (or Android emulator).
    • Starts the test server in the background.
    • Runs maestro test .maestro/apisauce-happy-path.yaml (and other flows as needed).
  • This job can be:
    • Required for master/release branches.
    • Or run nightly if runtime/cost is a concern.

Value:
This gives true RN integration coverage—apisauce calling through RN’s networking stack, real HTTP endpoints, and user-visible behavior—without complicating the core library’s build/test pipeline.

---

Phase 4 – RN-specific regression coverage & hardening (optional)

After the basic stack is in place, we can selectively add tests for:

• Known or anticipated RN-specific issues:
  • Axios upgrades that affected RN networking (timeouts, cookie behavior, connection errors).
  • RN-specific differences in error messages or status codes.
• Cross-platform nuances:
  • Confirm behavior on both iOS and Android when feasible (Maestro supports both).

These can be expressed as additional Maestro flows and, when appropriate, mirrored in Jest unit-level tests in the example app.

---

If you’d like, the next step from here would be:

1. Decide whether we want to use Ignite or plain React Native CLI for the example app.
2. Decide where RN E2E should run in CI (per-PR vs nightly).
3. Once those are agreed, I can draft a concrete implementation checklist (exact directories, package.json entries, and sample Maestro flows) for the first PR.

[jamonholmgren]

@CharlieHelps I think that if the tests don't run in a real Hermes / RN environment, they're not really any better than Node-based tests.

[charliecreates]

#338 (comment)

You’re right: if the tests don’t actually execute inside a real RN + Hermes runtime, they’re basically just a second set of Node tests.

The intent of the plan I sketched is:

• Keep Ava/Node as the main library tests.
• Add a small RN example app that’s built and run with Hermes enabled.
• Use Maestro to drive that app on a simulator/emulator so apisauce calls go through the RN XHR adapter in Hermes, not Node.

In that setup, the only tests I’d count as “React Native coverage” are the Maestro flows running against a Hermes-enabled RN build. The Jest tests inside the example app are just cheap smoke tests for bundling and service wiring; I can de‑emphasize or even drop them if that’s confusing the goal.

If that direction sounds right, I’ll tighten the proposal to explicitly require:

1. The example app to use a current RN with Hermes on.
2. CI jobs that build that Hermes-enabled app and run Maestro flows against it (starting with iOS, adding Android as a follow-up).

Let me know if you also want to target any specific Hermes/axios/RN failure modes in those flows (e.g., timeouts, connection errors, cookies), and I’ll bake them into the concrete checklist.

[jamonholmgren]

@CharlieHelps Let's move forward with the basic smoke test for now.

[charliecreates]

#338 (comment)

Sounds good — I’ll focus on a single Hermes-backed RN smoke test that proves apisauce works end-to-end in a real RN runtime, and leave everything else for later.

Basic Hermes RN smoke test plan

• Add a small React Native example app under examples/, using a current Hermes-enabled RN version, and depend on the local apisauce via file:../.. so it always tests the current branch.
• In that app, add a simple screen (e.g. ApisauceSmokeScreen) that:
  • Uses apisauce.create({ baseURL }).get('/status/200') (or similar) against a tiny Node test server.
  • Renders the resulting status, ok, and problem values so they’re easy to assert on.
• Add one automated E2E flow (likely with Maestro) that:
  • Boots the Hermes-enabled app in a simulator.
  • Navigates to ApisauceSmokeScreen, taps a “Run smoke test” button, and waits for the network call.
  • Asserts that ok === true and status === 200 are rendered in the UI.

Once that’s stable, we can grow it into additional scenarios (timeouts, connection errors, etc.) as follow-up work.

Unless you’d strongly prefer Ignite for the example app, I’ll start from a bare React Native CLI app to keep the footprint small and open a PR off ai-338-automated-react-native-tests-charliehelps with this single Hermes RN smoke test wired up.