-
Notifications
You must be signed in to change notification settings - Fork 272
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
Migrate to React Testing Library #97
Conversation
); | ||
}); | ||
|
||
test('provides elements and stripe with the ElementsConsumer component in Strict Mode', () => { |
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 doesn't actually test strict mode 🤦♀️
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.
Thanks for doing this!
const {result, rerender} = renderHook(() => useElements(), {wrapper}); | ||
expect(result.current).toBe(null); | ||
|
||
stripeProp = mockStripe; |
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.
nit: I get how this works, but it so badly breaks the React model that if feels like it should not. Can this be a bit more idiomatic?
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.
Yeah, does feel a bit weird (though it is what's prescribed in the React Hooks Testing Library). Because you expect that props should not be mutated outside of the React lifecycle, right?
Would this be preferable?
test('allows a transition from null to a valid Stripe object', () => {
const TestComponent = () => {
const elements = useElements();
if (!elements) {
return null;
}
if (elements === mockElements) {
return <>expected</>;
}
throw new Error(`unexpected useElements value: ${elements}`);
};
const {container, rerender} = render(
<Elements stripe={null}>
<TestComponent />
</Elements>
);
expect(container).toBeEmpty();
rerender(
<Elements stripe={mockStripe}>
<TestComponent />
</Elements>
);
expect(container).toHaveTextContent('expected');
});
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.
Updated this and the next, lemme know what you think.
); | ||
expect(result.current).toBe(null); | ||
|
||
stripeProp = mockStripePromise; |
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.
Same thing here.
src/components/Elements.test.tsx
Outdated
let stripeProp: any = null; | ||
const wrapper = ({children}: any) => ( | ||
<Elements stripe={stripeProp}>{children}</Elements> | ||
const TestComponent = () => { |
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 actually seems overly round-about. The way you had it before is fine once I get my head around it. Especially if the old way is the blessed way of testing.
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.
Cool, I'll leave it the original way then
This reverts commit dc99847.
#93 adds support for Strict Mode, but we don't have any way to make sure we don't regress this change since Enzyme doesn't support Strict Mode. This PR migrates our usage of Enzyme to React Testing Library, which does support Strict Mode, so that we can confidently merge #93.
A few notes about the migration: