My rule is: Don't snapshot today what you can't be bothered to look through a huge diff of tomorrow ... and the day after that ... :innocent:
So about testing-library. unexpected-dom is actually compatible to some extend with testing-library, you can use it for rendering and interacting with the DOM and use unexpected-dom to assert the DOM structure if you want.
About mocking and stubbing. I mock the network layer and just render components in a context where they have a fake network. It can be tedious depending on what kind of stack you are using, so if you can tell me that, then I might have some inputs. It is quite different what I would do with Redux and Apollo client.
I usually don't create about the DOM structure of the components that I use, we have a shared component library and that is fully tested, so I mainly test the semantics of the feature I'm bundling. I do that by using test ids and poke at the components to get them in the state I would like.
But I personally think we as a community have put way too much logic into React, so if you are on Redux as an example I would try to get as much logic into Redux as possible. That would make it possible to test all of that logic there, then you can mount your components with the state you want to present just by providing a Redux store. Your React components can be dumb and presentational as they were suppose to be. I know this is probably very hard to apply, but I think we went in the wrong direction with React.
Yes, you are right, it really seems the direction shift. I recently read the react-redux docs and their recommended approach is not longer sticking to separation of concerns with something like connect() but go for the hooks API instead. I have tried the Redux hooks in a recent project and had to change pretty much the setup of the tests.
A test looks something like that (sorry for the morning shot of code):
it("should call openDialogAction", () => {
[SomeComponent, store] = withStore(
SomeComponent,
merge({}, initialState, {
overview: {
data: {
plan: {
name: "Plan A",
total: 100,
usage: 100
}
}
}
})
);
store.dispatch = sinon.stub().named("dispatch");
const component = mount(<SomeComponent />);
simulate(component, {
type: "click",
target: "[data-test-id=upsell-link]"
});
expect(store.dispatch, "to have a call exhaustively satisfying", [
{ type: "@ui/DIALOG_OPEN", payload: { dialogName: "PLANS_DIALOG" } }
]);
});expect(SomeComponent, 'rendered with state', {...}, 'to satisfy', ...)- My advice is to move as much logic to Redux as possible and test it there.
- Test that components dispatch the correct actions when clicking on things.
- Test that components contains the correct test ids when rendered for a given state.
Waiting for your new library to emerge :)
I suppose we will then use uncontrolled forms fx. with that approach.
You can still use controlled forms, but you have to dispatch the changes, or you have to keep that state locally and dispatch it on submit.
But with libraries that isn't singleton and where you can make an entire application in 6.6KB JS would allow many teams to move freely without coordination.
Haha it is all work in progress, sorry for giving you such a long writeup.
Do you then pass store data the usual way with props?
You can get data from the store and from props, but any change can only start from the store. That might propagate through props.
@depository/view https://drive.google.com/file/d/137BVP3oZsL51EmG5dGqMgAqM8t1LONyG/view?usp=sharingI simply love the workflow.
