3 ms·
I like Cypress because it helps us easily validate when our backend teams introduce breaking API changes without notifying UI teams. Quality is often left to UI
by JMTQp8lwXL 6y ago
I like Cypress because it helps us easily validate when our backend teams introduce breaking API changes without notifying UI teams. Quality is often left to UI teams, when service teams need to step up and perform more due diligence of their own. Until then, Cypress is the tool for the job. Been using it for 6+ months. I'm not crazy about it, but I have no known superior alternatives, so I am grateful for this open source tech.
- sverhagen 6y agoThere are cheaper ways to validate APIs than Cypress and its class of tools. How about something of the likes of Postman (which is scriptable) or (oversimplified) a JavaScript file making calls combined with an assertion library? If your goal isn't to test a frontend, Cypress seems inappropriate.
- JMTQp8lwXL 6y agoFront end teams shouldn't have to write tests for other team's services. This is more of an organizational concern. We do care about testing the front end, but it more often reveals back-end issues than regressions in UI code.
- sverhagen 6y agoIt sounded like these tests were only written to validate the backend. Great if that's not the case. I agree that the backend team should test their own stuff. End to end testing is a poor substitute for that. There may be value, though, in having some (light?) validation of a dependency, ie. the frontend team validating that the backend is still there. I heard the latest SpringOneTour talk refer to this as "enemy testing". Maybe really bad for internal teams, but I can sympathize when the dependency is external and you don't know when to expect changes.