Whatever you do, try to make your tests resemble real use cases. You'll only be confident with your tests if they work the way your users do. With that in mind, we recommend this order of priority:
- Queries Users Can Interact With
getByLabelText: Your disabled users are counting on you, so this should likely be everywhere for their sake 😉 use it often, and if you aren't, maybe ask yourself why.
getByHintText: You should probably have an accessibility label that you can select by, but if for some reason you set this instead, it's safe to use.
getByPlaceholderText: Great for targeting a
TextInputelement to verify its content
getByText: Great for finding a
Touchablenode. You'll probably use this one a lot.
getByDisplayValue: This is good because a user can see the value they type into a
TextInputor whether a
Switchis on or off.
- Queries Users Can Infer
- Queries Users Don't Even Know About
getByTestId: The user cannot see (or hear) these, so this is only recommended for cases where you can't match by text or it doesn't make sense
If you absolutely can't find a way to get the element you're looking for, you can use
findAll as an escape hatch. Note that this is a bad practice and may
introduce unpredictable behavior in your tests. It would likely be better to use a
testID in most
cases where you need to.
Also note, this utility still won't be able to find your app's components, it will only search for React Native core components. This library provides you no reasonable way to make an assertion on your components.