-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: more meaningful AnimatedNumber component test #8309
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work on this @rahimrahman 💯
Left a couple of comments, but nothing blocking.
expect(animatedView).toBeTruthy(); | ||
}); | ||
|
||
describe.each([1, 23, 579, -123, 6789, 23456])('should show the correct number of animated views based on the digits', (animateToNumber: number) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more of a general question, but ideally, I'd like to find consistency in how we identify test cases, and in this specific instance, it seems like there's some pattern here (testing numbers with increasing digits + negative case).
I wonder whether some fuzz testing could be valuable in such cases rather than arbitrarily choosing some values. I don't have an answer here; I'm just curious to hear more thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this instance, the whole idea is to show how many views were created based on digits. We have 1, 2, 3, 4 (- is considered a "digit"), 4 and 5 digits in those examples.
} catch (e) { | ||
expect(e).toBeTruthy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for not using the .rejects.toThrow('error');
pattern in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because fireEvent() is not a promise and there's no rejection.
It still throws an error, because the View is no longer there (since it has been removed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few questions and one request for a helper method, but I definitely like the way this looks compared to the older version even for a more complicated component like this one
describe('AnimatedNumber', () => { | ||
// running on jest, since Animated is a native module, Animated.timing.start needs to be mocked in order to update to the final Animated.Value. | ||
// Ex: 1 => 2, the Animated.Value should be -20 (from -10) after the animation is done | ||
jest.spyOn(Animated, 'timing').mockImplementation((a, b) => ({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we likely to need this when testing other components? I wonder if we might want to mock this globally be adding it to test/setup.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
timing is taking a value from one to another at a certain duration, I don't care how long but in this example, I want animation.value to become b.toValue.
The implementation could be a bit more complicated like using easing, etc. So it might be unique in other test cases.
@rahimrahman Maybe I am missing something, but aren't we missing the snapshots on the PR? I am surprised the CI did not yell about that. Maybe something we should look into. |
I thought I copied this test from another test somewhere, but for the life of me, I couldn't figure out where now. Or, I wrote the original test to showcase how toMatchSnapshot() could be deceiving. With the thought of creating the newer test as educational purpose. |
@yasserfaraazkhan I didn't make any major changes to animated_number/index.tsx other than adding testID and using a better index for the views. I don't think it warrants even regression testing, but if you feel the need, do specify. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verified running the app locally on simulators. Checked for rections on a root post, threaded post. It worked as exptected.
* better unit test for animated_number * updated test * update test * clean up based on comments
Summary
This was presented during Developer Meeting October 30th. The goal was to ask developers to re-consider the use of toMatchSnapshot which doesn't really give enough information what the component AnimatedNumber is doing and why it's rendering the way it did.
In order to get coverage % when running this test, you'd have to temporarily update the jest.config.js file:
Ticket Link
Checklist
E2E iOS tests for PR
.Device Information
This PR was tested on:
Screenshots
Release Note