Closed Dujota closed 1 year ago
thanks a lot for sharing 🙏 I am used to doing the following
createStore({
....
})
<StateMachineProivder>
</StateMachineProivder>
in each of my test cases without the abstraction as you did. Maybe i should include an example in the read me.
I finally re-visited the topic issue#111 in order to resolve this outstanding item. Originally, I had opted for a workaround by completely mocking out LSM and its return values. Although this "works" and is very usefull when you just want to programatically manipulate component ui without any simulated interactions, this still did not resolve the root problem (How do I test the behaviour of a component that relies on LSM).
for example:
This is fine, when doing unit testing or just trying to assert some branching logic that depends on the store's current state value . Unfortunately it was not enough since I could not properly render the app in the same way a user would experience it, which was the original goal (test behaviour based on user interaction with app) .
Again, the goal is provide a seamless, automated way to render components in the same way that the application would spin up; wrapped in LSM provider without having to add repetitive boilerplate code to every test (we have over 900+ Test Suites).
So the issue boild down to this: LSM, when rendered by RTL/Jest env=jsdom, returned an empty object on initialization since its running in nodejs first then loaded into jsdom.
Solution:
The setup:
Usage: act is required for handling state updates caused by LSM
In summary, yes all tests should be wrapped by their own providers (which was original intent anyway), but LSM needs to initialize the store within a wrapper component so that the lib can load by the time the test comp gets rendered by RTL.
I hope this helps save some time for others since there's literally 0 examples out there.