feat: toHaveAccessibilityState() #124
Conversation
Codecov Report
@@ Coverage Diff @@
## main #124 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 9 10 +1
Lines 175 193 +18
Branches 57 60 +3
=========================================
+ Hits 175 193 +18
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
mdjastrzebski
requested review from
MichaelDeBoey,
thymikee and
brunohkbx
and removed request for
MichaelDeBoey
mdjastrzebski
changed the title
| expect(screen.getByTestId('view')).not.toHaveAccessibilityState({ checked: false }); | ||
| expect(screen.getByTestId('view')).not.toHaveAccessibilityState({ expanded: false }); |
There was a problem hiding this comment.
these 2 last examples confused me for a bit because we also have
expect(screen.getByTestId('view')).not.toHaveAccessibilityState({ checked: true });
expect(screen.getByTestId('view')).not.toHaveAccessibilityState({ expanded: true });did you check for false here to contrast with the other example below?
There was a problem hiding this comment.
Thanks for pointing this out. I will add additional docs to explain it. Basically for checked & expanded having false value is considered something different than not having value. While for disabled, selected and busy not having value equal to having false value.
Part of value proposition of this matcher is to encapsulate that behaviour.
There was a problem hiding this comment.
I've rewritten the docs, pls check if under current docs that makes more sense.
|
@MattAgn thanks for review |
|
@MattAgn Could you take another look, I've addressed all your comments. |
mdjastrzebski
force-pushed
the
feat/to-have-accessibility-state
branch
from
0cbef8e
to
cea85b1
Compare
|
🎉 This PR is included in version 5.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What:
Matcher for matching accessiblity state, that takes into account implied state.
Why:
Current
toHavePropis performing strict matching ofaccessibilityStateprop, while matching based only on some state entries is useful. AdditionallytoHavePropis not aware of implicit state entries.How:
Calculate implied
accessibilityStateusing the same rules as React Native Testing Library and match it only agains requested a11y state entries.Checklist:
@pierrezimmermannbam, @AugustinLF, @MattAgn pls take a look