-
Notifications
You must be signed in to change notification settings - Fork 690
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
react: Testing thrown errors #1060
Comments
We definitely want to document a good pattern for testing errors. But this should cover components as well not just hooks. |
result.error
when renderHook
render a hook that throw error
It is nice, but implantation of already made work not should be delayed by feature work on components |
To get the functionality that was previously available in (it's basically the same code as import type { RenderHookOptions } from '@testing-library/react';
import { render } from '@testing-library/react';
import * as React from 'react';
function customRenderHook<TProps, TResult>(
renderCallback: (initialProps: TProps) => TResult,
options: RenderHookOptions<TProps> = {},
) {
const { initialProps, wrapper } = options;
const result = {
current: undefined as TResult | undefined,
error: undefined as unknown,
};
function TestComponent({
renderCallbackProps,
}: {
renderCallbackProps: TProps | undefined;
}) {
let pendingResult: TResult | undefined;
let pendingError: unknown;
try {
pendingResult = renderCallback(renderCallbackProps!);
} catch (error) {
pendingError = error;
}
React.useEffect(() => {
result.current = pendingResult;
result.error = pendingError;
});
return null;
}
const { rerender: baseRerender, unmount } = render(
<TestComponent renderCallbackProps={initialProps} />,
{
wrapper,
},
);
function rerender(rerenderCallbackProps?: TProps) {
baseRerender(<TestComponent renderCallbackProps={rerenderCallbackProps} />);
}
return {
result,
rerender,
unmount,
};
}
export { customRenderHook as renderHook }; |
I agree with perymimon, you don't need to wait to have a component error resolution to raise the hooks error resolution. Now with the arrival of React 18 and the non-update of the lib |
The problem is that without understanding the problemspace fully we might create an interface that only works with hooks but not components. If we rush hooks implementation and later realize that it's not a good interface for testing errors in components, we have to either release another breaking change or fragment the testing landscape. Neither of these scenarios is ideal. We already have issues by letting To elaborate more on the issues I see with saving the last error:
From my experience it's probably better to move this to matchers i.e. provide an API along the lines of |
For anyone this may help, I wrote a very simple helper function to catch just an error thrown by a hook. I'm sure it can be improved, but I wanted to write a reusable function that didn't override
Here is an example of it in use: hooks/useCustomHook.js
hooks/useCustomHook.test.js
|
@eps1lon So.... we are letting documentation for a feature that doesn't exist yet block the implementation of said feature? Sounds a little like putting the cart before the horse to, as you put in this comment, "start with a documented pattern first before building any API around it." While it isn't the end of the world for me that React Testing Library can't handle errors (I have only one test in y-react that relies on this), it is annoying to see this get shoved under the rug. |
Describe the feature you'd like:
When I want to test a situation that my tested hook throws an expected error I like I have the option to test it without hacking the test code.
It will be greeted if the implementation that actually done on that subject on react-hooks-testing-library will be implemented on
@testing-library/react
Suggested implementation:
As describe here
result.error
should be hold the throwing object and accessing toresult.current
will should throw the error againThe text was updated successfully, but these errors were encountered: