For very simple cases, such as a Component that takes props but doesn't use any hooks, I am happy with the react-test-renderer package that comes with React but is now deprecated, although outputting JSON instead of HTML is a definite case of "test framework introduced another abstraction I don't need that makes me feel less in control".
Enzyme and react-test-library on the other hand have the potential to write a test like:
1. Mount component
2. Do something to the component (say click on a button)
3. Wait for React to settle down
4. Check that the component looks OK
Both Enzyme and RTL have many minor problems in 1, 2 and 4. For instance some CSS selectors that should work in Enzyme don't seem to. The html() method crashes sometimes in Enzyme. RTL's dependence on the accessibility tree answers some of the problems of "test automation" but it also is a statement that "three.js developers don't deserve to have a test framework". Also I have enough things to worry about with my code and getting it to actually work inside the test framework (like discovering whatever shibboleth it takes to get my useEffect callbacks actually called) that I don't have any mental capacity to fight with the accessibility tree and the Rube Goldberg machine that extracts it from HTML. Thus instead of seeing the HTML which the end user "sees" I have a bunch of abstractions that introduce more uncertainty in a situation where I'm already uncertain of just about everything.
And it is (3) that is the elephant in the room because what you have to do for (3) is dependent on your application and it can get pretty complicated. The root problem is that your code might set some value by calling setSomeValue but even in a rerender, value doesn't change until React does some work that is scheduled in a promise. And that promise could cause another promise to get queued and so forth so all you can do is set a long timeout and keep polling to check that your component has really settled down which is dependent on your component, the implementation of your component, etc. (Hint: if your "unit test" has a 1000ms timeout it's not really a unit test... For that matter, RTL is always warning you how slow it is to look up items by role)
Given that React is so prominent in the industry and that people seem to think testing is so important you'd think somebody would patch React or the node.js runtime if necessary to keep track to see if there are still promises so (3) can be as simple as
await done()
Looking at discussions in the ticket systems for the frameworks the developers seem to be as confused as everyone else.
As it was, if an evil billionaire had paid these framework developers to convince developers that testing is a total waste of time he'd be tickled pink by the results. Is anyone trying a different path? Is there a React testing framework developed by someone who actually tried writing tests for React?
Enzyme and react-test-library on the other hand have the potential to write a test like:
Both Enzyme and RTL have many minor problems in 1, 2 and 4. For instance some CSS selectors that should work in Enzyme don't seem to. The html() method crashes sometimes in Enzyme. RTL's dependence on the accessibility tree answers some of the problems of "test automation" but it also is a statement that "three.js developers don't deserve to have a test framework". Also I have enough things to worry about with my code and getting it to actually work inside the test framework (like discovering whatever shibboleth it takes to get my useEffect callbacks actually called) that I don't have any mental capacity to fight with the accessibility tree and the Rube Goldberg machine that extracts it from HTML. Thus instead of seeing the HTML which the end user "sees" I have a bunch of abstractions that introduce more uncertainty in a situation where I'm already uncertain of just about everything.And it is (3) that is the elephant in the room because what you have to do for (3) is dependent on your application and it can get pretty complicated. The root problem is that your code might set some value by calling setSomeValue but even in a rerender, value doesn't change until React does some work that is scheduled in a promise. And that promise could cause another promise to get queued and so forth so all you can do is set a long timeout and keep polling to check that your component has really settled down which is dependent on your component, the implementation of your component, etc. (Hint: if your "unit test" has a 1000ms timeout it's not really a unit test... For that matter, RTL is always warning you how slow it is to look up items by role)
Given that React is so prominent in the industry and that people seem to think testing is so important you'd think somebody would patch React or the node.js runtime if necessary to keep track to see if there are still promises so (3) can be as simple as
Looking at discussions in the ticket systems for the frameworks the developers seem to be as confused as everyone else.As it was, if an evil billionaire had paid these framework developers to convince developers that testing is a total waste of time he'd be tickled pink by the results. Is anyone trying a different path? Is there a React testing framework developed by someone who actually tried writing tests for React?