toBeDisabled() matcher behavior with Text component and onPress/disabled props

[rarenatoe]

I am migrating from @testing-library/jest-native/extend-expect to @testing-library/react-native/extend-expect.

Previously, with @testing-library/jest-native, I could successfully use toBeDisabled() on a Text component that had an onPress prop and was passed a disabled={true} prop.

After migrating to @testing-library/react-native, this test now fails.

My observation is that if a Text component has an onPress handler and is also passed a disabled={true} prop, the onPress callback does not fire on either Android or iOS. While there's no visual feedback (e.g., dimming), the functional interaction is prevented cross-platform.

Despite this functional disabling, toBeDisabled() from @testing-library/react-native fails, reporting:

Error: expect(element).toBeDisabled()

Received element is not disabled:
  <Text>
    Add
  </Text>

Debugging shows screen.getByText('Add').props.disabled is indeed true.

Question:

Is this change in toBeDisabled() behavior for Text components (which functionally prevent onPress when disabled={true}) intended as part of the migration? I'm seeking clarification on whether Text components, when used interactively via onPress and then functionally disabled, are expected to be recognized by toBeDisabled().

Reproduction Steps:

1. Create a simple React Native component:

   import React from 'react';
   import { View, Text, Alert } from 'react-native';
   
   const MyTextButton = ({ isDisabled }) => {
     return (
       <View>
         <Text
           onPress={() => Alert.alert('Tapped!')}
           disabled={isDisabled} // This prop makes onPress non-functional on both platforms
           style={{ padding: 10, borderWidth: 1, borderColor: 'black' }}
           testID="my-text-button"
         >
           Tap Me
         </Text>
       </View>
     );
   };
   
   export default MyTextButton;

2. Create a test file:

   import React from 'react';
   import { render, screen, userEvent } from '@testing-library/react-native';
   import MyTextButton from './MyTextButton';
   
   describe('MyTextButton', () => {
     it('should be functionally disabled when prop is true but toBeDisabled() fails', async () => {
       render(<MyTextButton isDisabled={true} />);
       const textButton = screen.getByTestId('my-text-button');
   
       const alertSpy = jest.spyOn(Alert, 'alert');
       await userEvent.press(textButton);
       expect(alertSpy).not.toHaveBeenCalled(); // This passes, confirming functional disablement
       alertSpy.mockRestore();
   
       expect(textButton).toBeDisabled(); // This assertion fails
     });
   });

3. Run the tests.

Versions:

• @testing-library/react-native: [Your Version, e.g., 12.9.0]
• @testing-library/jest-native: 5.4.3 (context for previous behavior)
• react-native: [Your Version, e.g., 0.77.2]

---

[mdjastrzebski]

@rarenatoe it seems you're right. The RN Text component has a disabled prop. If that worked in Jest Native, it has probably got lost when re-implementing Jest matchers into core RNTL.

Would you like contribute PR to toBeEnabled()/toBeDisabled() matchers to cover this case?

[jerone]

Please note that the disabled property is Android only.

I'm mentioning it, because I'm having an similar issue, but with <Switch/>.
Adding disabled={true} on the switch and then using expect(elm).toBeDisabled() works for Android, but fails on iOS.

[mdjastrzebski]

@jerone it's ok, RNTL currently approaches iOS/Android platform differences with approach of accepting given prop/behavior if it works either on iOS or on Android. There is no different mode for each platform.

[rarenatoe]

Please note that the disabled property is Android only.

I'm mentioning it, because I'm having an similar issue, but with <Switch/>. Adding disabled={true} on the switch and then using expect(elm).toBeDisabled() works for Android, but fails on iOS.

According to the documentation is android only, but I've tested it on both the android emulator and iOS simulator and it works on both.

[rarenatoe]

@rarenatoe it seems you're right. The RN Text component has a disabled prop. If that worked in Jest Native, it has probably got lost when re-implementing Jest matchers into core RNTL.

Would you like contribute PR to toBeEnabled()/toBeDisabled() matchers to cover this case?

Thanks @mdjastrzebski I'd be happy to, but I'm a bit lost on what is required and I don't know if I have the time right now, perhaps next week.

[mdjastrzebski]

Basically you would have to add your condition to toBeEnabled/toBeDisabled body, write 1-2 tests to validate it, and update the docs if needed.