English Vocabulary for Detox Mobile Testing

Detox is a grey-box end-to-end testing framework for React Native applications. It allows developers to write automated tests that run directly on a simulator or device, interacting with the UI just as a real user would. If you work with Detox and collaborate in English, having the right vocabulary will help you write clearer test plans, discuss test failures, and advocate for testing practices in your team.

Key Vocabulary

Grey-box testing Grey-box testing refers to a testing approach that has some visibility into the internal workings of the application under test, without having full access to the source code. Detox is described as grey-box because it can monitor the application’s internal state (such as whether the JavaScript thread is idle) to synchronise test interactions reliably. Example: “Detox’s grey-box approach means it knows when the app is ready for the next interaction, which makes tests much more reliable than timing-based approaches.”

Synchronisation In Detox, synchronisation refers to the framework’s ability to wait for the application to reach an idle state before executing the next test action. This eliminates the need for manual sleep calls and makes tests more stable. Example: “Detox handles synchronisation automatically — it waits for network requests and animations to complete before proceeding to the next assertion.”

Matcher A matcher is a query that identifies a UI element in the Detox test. Elements can be matched by their test ID, accessibility label, text content, or other attributes. Example: “We use testID attributes on our components to make them easy to target in Detox matchers.”

Action An action is an interaction with a UI element in a Detox test — such as tapping, swiping, typing text, or scrolling. Actions are applied to elements found by matchers. Example: “After finding the login button with a matcher, we apply a tap action to simulate the user pressing it.”

Expectation An expectation is an assertion in a Detox test that verifies that the UI is in the expected state after an action has been performed. Example: “After submitting the form, we have an expectation that the success message is visible on screen.”

Common Scenarios Where This Language Is Used

In a test planning meeting: “We’re adding Detox tests for the critical user journeys — login, onboarding, and the purchase flow. I’ll start with the happy path for each journey, and then we’ll add edge cases in a second pass.”

When discussing a flaky test: “The checkout-flow Detox test has been failing intermittently in CI. I suspect it’s a synchronisation issue — the test is interacting with the payment button before the loading state has cleared. I’ll add an explicit wait for the element to be enabled.”

In a code review: “I notice this test uses sleep(2000) instead of letting Detox handle synchronisation. We should remove the sleep — Detox will wait automatically for the network request to complete.”

When setting up Detox in a new project: “Getting Detox configured correctly takes some effort — you need to set up the test runner configuration, build a specific binary for testing, and configure the simulator. I can pair with you to get the initial setup done.”

Useful Phrases for Detox Testing Discussions

• “Detox runs end-to-end tests on a real simulator, interacting with the UI as a user would.”
• “We’ve written Detox tests for all our critical user flows — login, onboarding, and checkout.”
• “The test is flaky — it fails about one time in ten in CI. I think it’s a synchronisation issue.”
• “We use testID props on interactive elements to make them reliably targetable in tests.”
• “Detox handles synchronisation automatically, so we don’t need manual delays in our tests.”
• “The matcher finds the element by its testID, and then we apply a tap action to it.”
• “After the action, we assert that the success screen is visible using an expectation.”
• “Detox tests are slow compared to unit tests — we run them only on pull requests to the main branch.”
• “We use Detox in combination with Maestro for some flows — Detox for JavaScript-heavy interactions, Maestro for simpler UI flows.”
• “The CI job runs the Detox tests on an iOS 17 simulator and an Android 14 emulator.”

Writing Clear Test Descriptions

Good Detox test descriptions help the team understand what is being tested and why a failure matters. Use the format “given/when/then” or a natural language description that clearly states the scenario.

Weak: it('should work correctly') Strong: it('displays an error message when the user submits an empty email field')

The test name should be specific enough that when a CI run fails, the person reviewing the failure report immediately understands what broke and which user-facing behaviour is affected.

When writing a comment explaining a complex test setup, be explicit: “We need to navigate to the settings screen before this test because the feature we’re testing is only accessible from there. The beforeEach block handles this navigation.”

Practice Suggestion

Take a critical user journey in a mobile app you use regularly — for example, creating an account, sending a message, or making a purchase. Write a Detox test plan in English (not code, but a structured plain-language description) covering: the test objective, the preconditions, the step-by-step user actions to be simulated, the assertions to be made after each action, and any known edge cases to test. This kind of test planning document is valuable both for writing the tests and for reviewing them with non-technical stakeholders.