fix: `.toHaveValue()` / `.toHaveFormValues()` on input type range now expect a number
What:
This PR aim to fix https://github.com/testing-library/jest-dom/issues/364.
Why:
In my use case on a react app, i'm using a constant that is a number for a default value of an input type range. I couldn't use it in my test without hacking a bit since .toHaveValue() were expecting a string instead of a number.
How:
It makes jest-dom consider <input type="range /> value getter the same as <input type="number" />
Checklist:
- [X] Documentation
- [X] Tests
- [x] Updated Type Definitions
- [X] Ready to be merged
I consider this change as a breaking change since it would break any test related to range inputs.
Hey there :wave: the PR template mention to Update type definitions but i didn't manage to find any in the repo. Could you point me were are those ?
Thanks :smile:
Codecov Report
Merging #365 (4f4774b) into main (948d90f) will not change coverage. The diff coverage is
100.00%.
:exclamation: Current head 4f4774b differs from pull request most recent head bf8c8c5. Consider uploading reports for the commit bf8c8c5 to get more accurate results
@@ Coverage Diff @@
## main #365 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 26
Lines 630 616 -14
Branches 236 224 -12
=========================================
- Hits 630 616 -14
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/utils.js | 100.00% <100.00%> (ø) |
|
| src/to-be-invalid.js | 100.00% <0.00%> (ø) |
|
| src/to-be-visible.js | 100.00% <0.00%> (ø) |
|
| src/to-have-class.js | 100.00% <0.00%> (ø) |
|
| src/to-have-focus.js | 100.00% <0.00%> (ø) |
|
| src/to-be-disabled.js | 100.00% <0.00%> (ø) |
|
| src/to-have-accessible-name.js | 100.00% <0.00%> (ø) |
|
| src/to-have-accessible-description.js | 100.00% <0.00%> (ø) |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
This looks good, but should we leave the breaking changes for a major release or consider this a bug fix?
FWIW, I was planning to take some time next week to gather this and at least one other PR that are breaking changes, and make a single new major release with them all. I was also planning to include in this major release the removal of all the custom matchers that we already have marked as deprecated for various versions now. There are 2 or 3 of them.