You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 15, 2019. It is now read-only.
We should try to write some integration tests to evaluate if they offer some benefits. Corrently I can think of these:
Can replace some of the e2e tests while being much faster. IMO we still need e2e test for each feature, but maybe not for the edge/error cases, because our e2e suite takes about 4 minutes and is growing with every new feature.
Can mock API responses to test API error cases which we cannot test in e2e tests, where we cannot make the server to return an error when we want.
Actual behaviour
We use unit tests and e2e tests, but no integration tests.
The text was updated successfully, but these errors were encountered:
@slaweet One pattern I've seen to make e2e tests more wieldy is to add a @critical tag to the most important scenarios, and run that subset more frequently than the full suite.
Expected behaviour
There are many blog posts out there on how to do integration tests with Mocha and Enzyme
https://engineering.classdojo.com/blog/2017/01/12/integration-testing-react-redux/
https://medium.freecodecamp.org/real-integration-tests-with-react-redux-and-react-router-417125212638
We should try to write some integration tests to evaluate if they offer some benefits. Corrently I can think of these:
Actual behaviour
We use unit tests and e2e tests, but no integration tests.
The text was updated successfully, but these errors were encountered: