UnitControl: rewrite tests in TypeScript #40697
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ciampo
added
[Type] Bug
ciampo
requested review from
mirka,
stokesman,
andrewserong and
aaronrobertshaw
ciampo
commented
Apr 28, 2022
Comment on lines
138
to
139
| // The unit is not being displayed! | ||
| const label = screen.getByText( '%' ); |
There was a problem hiding this comment.
Currently this line is failing in unit tests — that's because we switched from just checking that an element with class components-unit-control__unit-label exists, to actually looking for the unit label being displayed (testing-library FTW!)
I'm not sure if we should call this a bug, though. Technically we're not passing any value to UnitControl, and therefore the component internally has not value to parse a unit from. If we passed value="30%", then this test would pass.
If our expectations are that UnitControl would display the % unit, for how the component is coded right now, it would mean that effectively the selected unit is % (which would also be reflected in the new components's value and probably fired through the change callbacks). Would that be a correct behavior to expect? I'm personally not so sure.
There was a problem hiding this comment.
From how I'd interpret it, the purpose of this test is exactly what it says: "should render label if single units". The fact that it's rendered with no value defined is just an oversight, and I think the original PR confirms that (#33634).
I think we should just render it with value="30%" like you suggest.
There was a problem hiding this comment.
I think we should just render it with
value="30%"like you suggest.
I went ahead and did this in 8929d0b (which should fix the tests for now).
I still decided to look into this a bit more, and therefore I decided to add a couple of Storybook examples for this scenario:
- One closely representing the failing unit test (e.g. uncontrolled
UnitControlwith just one unit) - Another one where
UnitControlis controlled, but its starting value isundefined(still with just one unit)
In the controlled case, the unit is not visible when value is set to undefined (its starting value). The unit then becomes visible when a number is entered, and stays visible even if those numbers are deleted (likely because the value becomes an empty string rather than undefined):
unit-control-single-unit-controlled.mp4
In the uncontrolled case, the unit is never shown even after the user enters a value:
unit-control-single-unit-uncontrolled.mp4
There was a problem hiding this comment.
Huh, good investigation! I would expect that when there is only one unit, the unit would be visible at mount and stay visible no matter what. This kind of seems like a common use case so I'd say it's worth fixing if it isn't too hard. What do you think?
|
Size Change: +1.03 kB (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
mirka
reviewed
Apr 29, 2022
Comment on lines
138
to
139
| // The unit is not being displayed! | ||
| const label = screen.getByText( '%' ); |
There was a problem hiding this comment.
From how I'd interpret it, the purpose of this test is exactly what it says: "should render label if single units". The fact that it's rendered with no value defined is just an oversight, and I think the original PR confirms that (#33634).
I think we should just render it with value="30%" like you suggest.
mirka
approved these changes
Apr 29, 2022
|
I wonder if this bug would be fixed by the changes in #40518 and #40568 Since this PR doesn't introduce any new features / fixes, I'm going to hold and merge it only after #40518 and #40568 are merged. This will also avoid introducing conflicts in those PRs (which are already quite complex and introduce changes to the same unit tests that this PR touches). |
|
This all looks good to me.
I looked into this and it seems the single unit A one-liner can fix it. Maybe I'll put it in a PR.diff --git a/packages/components/src/unit-control/index.tsx b/packages/components/src/unit-control/index.tsx
index 089155b9d2..00810c45ef 100644
--- a/packages/components/src/unit-control/index.tsx
+++ b/packages/components/src/unit-control/index.tsx
@@ -88,7 +88,7 @@ function UnforwardedUnitControl(
);
const [ unit, setUnit ] = useControlledState< string | undefined >(
- unitProp,
+ units.length === 1 ? units[ 0 ].label : unitProp,
{
initial: parsedUnit,
fallback: '',
I think it's fine if you want to go ahead and an merge this as any conflict would be trivial to resolve. Actually, if you were to add any missing |
|
Thank you for the help in coordinating around these changes! I went ahead and merged this PR as-is. I'm going to open 2 follow-ups:
(will update this message with links to those PRs once opened) |
This was referenced May 3, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Rewrite
UnitControl's unit tests to TypeScript, and add a few related tweaks/fixes that were highlighted by the refactor.Why?
See #35744 for more context.
How?
toBeInTheDocument,getByRole...)TODO: maybe add another bug fix changelog entry (see comment below)
Testing Instructions