Adding a Minimal Test Safety Net to Rork-Generated Screens

The minimal setup (Jest and React Native Testing Library)

This assumes an Expo project exported from Rork. You need two libraries and a short config.

# Add as dev dependencies (not bundled into the shipped app)
npm install --save-dev jest jest-expo @testing-library/react-native @testing-library/jest-native

Then add a test command and the base Jest config to package.json.

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch"
  },
  "jest": {
    "preset": "jest-expo",
    "setupFilesAfterEnv": ["@testing-library/jest-native/extend-expect"],
    "transformIgnorePatterns": [
      "node_modules/(?!((jest-)?react-native|@react-native(-community)?|expo(nent)?|@expo(nent)?/.*|@react-navigation/.*))"
    ]
  }
}

Without that transformIgnorePatterns, loading Expo packages throws a syntax error. I lost about 30 minutes here on my first try. It is the classic stumbling point when adding your own tests to generated code, so I recommend putting it in from the start.

Once npm test runs, the net is in place.

Lock the paywall gate with a single test

The very first thing to write is the paid-feature lock check. In most generated code, this logic is gathered into one function or hook. Suppose there is a function called canUsePremiumFeature.

// premiumAccess.ts (the lock logic already present in generated code)
type Entitlement = { active: boolean; expiresAt: number | null };
 
export function canUsePremiumFeature(
  entitlement: Entitlement,
  now: number
): boolean {
  if (!entitlement.active) return false;
  if (entitlement.expiresAt === null) return true; // lifetime purchase
  return entitlement.expiresAt > now; // allow only while valid
}

Pin the promise with a test. The key is to verify the relationship between input and output, not the internals.

// premiumAccess.test.ts
import { canUsePremiumFeature } from "./premiumAccess";
 
const NOW = 1_700_000_000_000;
 
describe("paid feature lock", () => {
  it("non-purchasers stay locked at all times", () => {
    expect(canUsePremiumFeature({ active: false, expiresAt: null }, NOW)).toBe(false);
  });
 
  it("lifetime buyers are allowed with no expiry", () => {
    expect(canUsePremiumFeature({ active: true, expiresAt: null }, NOW)).toBe(true);
  });
 
  it("expired subscriptions are not allowed", () => {
    expect(canUsePremiumFeature({ active: true, expiresAt: NOW - 1 }, NOW)).toBe(false);
  });
});

Just three tests, but now a machine stops the "paid feature leaks to non-purchasers" accident. Flip the check by mistake during a refactor, and npm test goes red.

Scope snapshots to price labels only

Snapshot testing records a screen's whole output and watches for diffs. It is convenient, but applied to an entire screen, every small decorative change breaks the test and drags you into update chores.

So I scope snapshots to the amount display alone. Prices are unforgiving — a wrong digit or currency symbol leads straight to refunds and complaints — while their appearance rarely changes, which makes them a great fit.

// PriceLabel.test.tsx
import { render } from "@testing-library/react-native";
import { PriceLabel } from "./PriceLabel";
 
it("Japanese yen renders with thousands separators and the yen sign", () => {
  const { getByText } = render(<PriceLabel amount={2480} currency="JPY" />);
  expect(getByText("¥2,480")).toBeTruthy();
});
 
it("zero falls back to a free label", () => {
  const { getByText } = render(<PriceLabel amount={0} currency="JPY" />);
  expect(getByText("Free")).toBeTruthy();
});

Instead of the whole screen, pull out only the one string you care about with getByText. Unrelated UI changes no longer break the test, and only the correctness you want to guard remains.

Write the failing test first

When adding tests to generated code, there is an order I recommend: for the behavior you want to fix, write a failing test first.

For example, if you notice a bug where an expired subscription still shows the paid feature, write one test that reproduces it before fixing anything. Confirm it goes red, then fix the code. When it turns green, you have proof the bug is actually gone.

This order has another benefit. If the same bug ever sneaks back in, that test catches the second occurrence. Generated code is prone to reopening the same hole on regeneration or large rewrites, so this "anti-regression stake" pays off.

Where to put tests, and whether to run CI

Placing the test file next to its target as .test.ts is the practical choice — easy to find later. Gathering everything into a distant __tests__ folder obscures which code each test protects.

Whether to build CI (automated runs) depends on scale.

Because I run several apps at once, I lean on automated runs. That said, as a first step, even running it by hand cuts generated-code accidents considerably.

A no-stress order for adding tests to existing generated code

Trying to clean up everything at once will wear you down. When bolting onto an app already in production, this order is realistic.

1. Put three tests on the paywall gate logic only
2. Add one snapshot for the price display
3. Confirm core navigation with a single test
4. Add a regression test at each spot a bug appears

With this order, the most painful-to-break places are protected in the first 30 minutes. I recommend prioritizing branches that affect AdMob ad display or your paid-conversion rate.

The pitfall is aiming for coverage from the start. Coverage is an outcome, not a goal. Dealing with the places that actually broke in production, one at a time, lasts longer in solo development.

Your next step

Start by putting three tests on the paywall logic. That alone removes one of the most painful accidents. Widen the protected area only as the number of places that have burned you grows.

Testing is not a coverage race; it is a map that lets you refactor with confidence. The longer you live with generated code, the more this small map quietly earns its keep.