`renderHook` from /dom/pure has global side-effects

• react-hooks-testing-library version: 5.0.0
• react-test-renderer version: not installed
• react version: 17.0.1
• node version: 17.0.1
• npm (or yarn) version: yarn@1.22.0

Relevant code or config:

const { renderHook } = require("@testing-library/react-hooks/dom/pure");

let consoleError;
beforeEach(() => {
  consoleError = console.error;
});

afterEach(() => {
  if (console.error !== consoleError) {
    throw new Error("Did not cleanup console.error");
  }
});

test("pure", () => {
  function useHook() {
    return useState(false);
  }

  const { result } = renderHook(() => useHook(), {});
});

What you did:

Use @testing-library/dom/pure in karma-mocha though the problem happens in arbitrary testing frameworks I suspect

What happened:

console.error was not cleaned up

Reproduction:

https://github.com/eps1lon/testing-library-react-hooks-impure

Problem description:

We check for mistakes in afterEach if a test was not properly cleaned up. One of those checks looks at console.error.

Suggested solution:

renderHook probably has some global side-effects. These should be documented by explaining why they exists and how to disable them or work around them.

[eps1lon]

I believe that any time you introduce a new library into your project you should take the time to learn about it and it’s behaviour.

This is just not reality but I can’t tell you that. I can only show you that. Maybe me, as a testing-library maintainer, being confused by this behavior helps you understand why this mentality is problematic.

So we still have the documentation issue. This behavior is underdocumented which is especially problematic since it’s not far fetched to assume that these libraries work similarly considering they are under the same org.

Anyway, I’ll be using a thiner wrapper in the future that doesn’t require to learn a new library. Getting co-workers on board with testing is hard enough. Expecting them to learn yet another library is not viable.

[mpeyper]

It’s not about where this happens for me. The problem I see is that /react works different than /react-hooks. So if I’m a user of /react and introduce /react-hooks (and vice versa) I also have to learn about new library behavior.

This is where I think our philosophies diverge a bit. While this library was inspired by, and much of the original implementation did indeed come from react-testing-library, at the end of the day they are trying to solve different problems which is why they have different implementation and behaviour. I believe that any time you introduce a new library into your project you should take the time to learn about it and it’s behaviour.

For example, rendering a hook with /react-hooks creates a completely different flow than rendering the same hook in a component with /react. This feels a lot like we’re going back to testing implementation details. This is already what we’re doing by testing the hook itself but I always justified it with “it’s just rendering a component that let’s me access the return value of a hook”.

If all this library did was wrap the hook call in a component and remove a handful of lines out of your test file then I don’t think we would exist at all.

Fundamentally, hooks are not components and components are not hooks. They have different use cases and different lifecycles. The more we see users moving their complex logic into custom hooks and the more we see people wanting to ensure all the ways that hook will behave, the more use cases we are going to try to support.

The more features we only add to /react-hooks the more we’re slipping back into testing implementation details.

I’m not sure what this basis for this commentary is. I don’t believe that that a user wanting to test that triggering an effect that causes an error to be thrown is testing implementation detail. I do believe that the user having to deal with the console output from our use of an error boundary is an implementation detail and is what we were trying to trying to protect them from.

If React didn’t log the error and we didn’t patch console.error would you still have a concern? Is the problem just that we messed up and don’t restore the the console for the pure import (a legitimate issue with the current version and one we are attempting to fix).

Is the concern that we have have result.error instead of allowing the error to bubble out to the test code? I’ve mentioned a few times that I’d love to remove it, but I haven’t been able to have it raise out in all instances where I believe it would be important. It was implemented before act existed so it may be possible now and I am planning on trying to try it it again, but I stumble somewhere every time I’ve tried before, usually around async update to state that case the error on a subsequent render.

---

Please don’t feel like I’m being dismissive of your concerns here. I’m genuinely trying to understand and think about what the implications of this discussion might be to the library in the future.