4 ms·
Can you expand upon this? I do a lot of frontend work, and I am slowly getting into the mindset that nearly all testing we do in react using enzyme is worthless
by azemetre 8y ago
Can you expand upon this? I do a lot of frontend work, and I am slowly getting into the mindset that nearly all testing we do in react using enzyme is worthless compared to doing e2e tests with something like cypress.
I rather not have people on my team waste hours writing tests that break the moment props change, or styling changes, or a child component renders breaking the test because they used mount instead of shallow. IDK, I think I just hate Enzyme mostly...
- monksy 8y agoIn frontend work, you're a little bit of a disadvantage due to the language and what you're testing. If you're testing interface code (something that draws something on the screen) the only way you can test that is if you have a really good testing library that will test it in a virtual drawing space or function/feature tests. With the backend you should have 90% unit tests (1000s of them) all completing in less than 3 minutes, integration tests (7% of all your tests) competing in under say 10 minutes, and feature tests (those shouldn't be in the build but in a post build step that can reject a change)
- avinium 8y agoI disagree - your “90%/7%/3%” seems completely arbitrary. It might be appropriate for some projects but I think it’s wrong to adopt as a hard and fast rule. IMO, the correct amount of testing is the amount that lets you refactor quickly and with confidence that you haven’t broken anything, and that tests pathways/edge cases in complicated logic.