feat: add toBeVisible matcher

[fluiddot]

What:

Add toBeVisible matcher following a similar logic as the jest-dom matcher (reference).

Why:

This matcher provides a useful way to verify that a queried element is actually visible.

How:

The matcher has been introduced based on the implementation of other matchers and trying to reproduce a similar logic as the jest-dom matcher (reference), but taking into account the React Native nuances.

Checklist:

• [x] Documentation added to the docs
• [x] Typescript definitions updated
• [x] Tests
• [x] Ready to be merged

[fluiddot]

Great work! This matcher would be quite useful. I left a few comments to consider.

Thank you very much @dcalhoun for taking a look at this PR 🙇.

Following your comments and suggestions, I've applied some updates to the changes. At this point, the PR can be considered as ready to be reviewed in order to include the new toBeVisible matcher.

[fluiddot]

Looks like most of the unit tests are failing with the following error:

TypeError: _interopRequireDefault is not a function

However, I managed to reproduce the same issue by running the tests in the main branch, so not sure whether these changes might be the cause 🤔 .

[dcalhoun]

@mdjastrzebski @thymikee would either of you be willing to review this work please? Totally understand if you do not have time currently. Just wanted to check in. Thanks! 🙇🏻

[GuglielmoFelici]

Hi all! Any update on this? Would be quite useful 🙌

[mdjastrzebski]

I will try to work on that next week

[Norfeldt]

I will try to work on that next week

Don't know if this would be of any help @mdjastrzebski . I'm using this:

expect.extend({
  // should be replacable once this PR gets merged https://github.com/testing-library/jest-native/pull/73
  toHaveZeroOpacity(element) {
    let pass = element.props.style?.opacity === 0
    let parent = element.parent
    while (parent && pass === false) {
      if (parent.props.style?.opacity === 0) pass = true
      parent = parent?.parent
    }

    return {
      message: () => 'expected element to be hidden',
      pass,
    }
  },
})

import { render } from '@testing-library/react-native'
import * as React from 'react'
import { View, Text } from 'react-native'

describe('extended `expect` methods', () => {
  describe('.toHaveZeroOpacity', () => {
    it('should pass when element is has zero opacity', () => {
      const utils = render(<View style={{ opacity: 0 }} testID="TestId__VIEW" />)
      expect(utils.getByTestId('TestId__VIEW')).toHaveZeroOpacity()
    })

    it('should NOT pass when element is has non-zero opacity', () => {
      const utils = render(<View style={{ opacity: 0.001 }} testID="TestId__VIEW" />)
      expect(utils.getByTestId('TestId__VIEW')).not.toHaveZeroOpacity()
    })

    it('should pass when some parent element is has zero opacity', () => {
      const utils = render(
        <View style={{ opacity: 0 }}>
          <View>
            <Text>invisible</Text>
          </View>
        </View>
      )
      expect(utils.getByText(/invisible/i)).toHaveZeroOpacity()
    })

    it('should pass when NO parent elements has zero opacity', () => {
      const utils = render(
        <View>
          <View>
            <Text>invisible</Text>
          </View>
        </View>
      )
      expect(utils.getByText(/invisible/i)).not.toHaveZeroOpacity()
    })
  })
})

[tomwaitforitmy]

I would be very happy to use this! 👍

[mdjastrzebski]

@fluiddot Do you have capacity to work on updating this PR?

@dcalhoun, @Norfeldt & others: maybe you are willing to take over this.

re isInaccessible function/respectAccessiblity option from RNTL: it seems that to toBeVisible from Jest DOM has slightly different logic than isInaccessible from DTL, as it e.g. takes into account opacity: 0. So this matcher should not sole rely on isInaccessible.

[fluiddot]

@fluiddot Do you have capacity to work on updating this PR?

Hey @mdjastrzebski, my apologies for not being very active in the PR. I'd like to resume the work on this and review the feedback as soon as possible, but my bandwidth nowadays is usually low. If someone is willing to take over this, please feel to do it. Otherwise, I'll try to make some progress in the next weeks.

[mdjastrzebski]

@fluiddot Overall the current implementation looks solid. I think it's sensible approach to base it on Jest DOM matcher code with some tweaks to adjust for different props in RN than in Web.

[mdjastrzebski]

@fluiddot would you be able to rebase the code and migrate it to typescript as the current codebase uses it now.

[fluiddot]

@fluiddot would you be able to rebase the code and migrate it to typescript as the current codebase uses it now.

@mdjastrzebski 😅 Sorry for the long delay on addressing the comments of the PR and migrating the changes to TypeScript. After the recent changes I pushed, the PR should be ready for another review. Let me know if there's anything else I can contribute with in order to conclude the feature. Thank you very much for the help 🙇 .

[codecov[bot]]

Codecov Report

Merging #73 (7267da4) into main (beaf547) will not change coverage. The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #73   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         9    +1     
  Lines          151       175   +24     
  Branches        47        57   +10     
=========================================
+ Hits           151       175   +24     

Flag	Coverage Δ
node-14	100.00% <100.00%> (ø)
node-16	100.00% <100.00%> (ø)
node-18	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/extend-expect.ts	100.00% <ø> (ø)
src/to-be-visible.ts	100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[mdjastrzebski]

@fluiddot looks pretty solid. I think the code is ready, I've added some tweak to code comments. Pls fix code coverage back to 100%. It should be a matter of adding a single test probably.

[fluiddot]

@fluiddot looks pretty solid. I think the code is ready, I've added some tweak to code comments. Pls fix code coverage back to 100%. It should be a matter of adding a single test probably.

Thanks for the review @mdjastrzebski 🙇. I've just applied your suggestions and typo fixes. I'll take a look at the code coverage and try to add another test to provide 100% 👍.

[fluiddot]

@fluiddot looks pretty solid. I think the code is ready, I've added some tweak to code comments. Pls fix code coverage back to 100%. It should be a matter of adding a single test probably.

Thanks for the review @mdjastrzebski 🙇. I've just applied your suggestions and typo fixes. I'll take a look at the code coverage and try to add another test to provide 100% 👍.

I added a new test for checking that the matcher throws an error when the expectation is not matched. With this, the coverage should go back to 100% 🎊.

[github-actions[bot]]

:tada: This PR is included in version 5.1.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[fluiddot]

Looks good! Happy to finally merge it :-) Thank you @fluiddot for this contribution!

Thank you so much @mdjastrzebski for the review and help of this contribution 🙇! Happy to know that it's finally merged 😃!