What's your backend written in? I'm in a similar position where work is pushing cypress, but there is no library for cypress in our backend language, there is for playwright. I want to do something in the frontend, and check the backend, so it would be nice to use our existing backend language for both so we have access to our internal library. I was told we could write a bash script and have cypress exec. Of course we can do a script in any language, but suddenly I'm seeing a bash QA library emerging at my work. Does that sound absurd to anyone else?

What do you mean with "check the backend"? You can e.g. do assertions on HTTP-responses coming from the backend - is this what you head in mind?

If you want to test the backend on its own, I personally would recommend using a different framework than cypress (or a different framework than the one being used for frontend e2e testing in general). Otherwise you risk that people conflate these two things and start "testing the backend" in e2e-tests for the frontend, which are super slow.

Yeah, specifically that interfacing with the ui causes some side effects we would expect to happen (web hooks sent, reports generated, etc). I definitely wouldn't want to write all of our tests that way, because that sounds like a nightmare to maintain and run, but was considering a handful for covering a few major features. We do already have a very extensive backend integration test suite (http / rest interactions) that doesn't do anything with UIs, though.

Cypress is a recent addition for us, so this is more a curiousity than anything else. I've done similar fully e2e / functional tests with puppeteer in the past.

Our backend is in node / typescript, so it's theoretically possible to mix the two. I would be able to test what I need using REST APIs, though, so in theory the backend language doesn't really matter for me.

I haven't had much time to try anything yet, but cypress's override of promises and async / await makes me think it'll be a pain to try adding non-cypress-specific checks to a cypress test.

Ideally you should not combine Cypress Frontend end to end tests with backend testing.

You use Cypress to do something on the frontend, which triggers something on the backend and ideally that change is reflected on the frontend, you test that frontend change using Cypress.

For backend testing just directly call the backend API's and then check the database directly.

There is a difference between integration testing (Cypress UI click through UI) and backend unit testing.

We run integration tests with Cypress and then rspec or some other Rails testing platform for the backend.

Cypress uses fixtures so ideally you would not let it hit a backend API unless you don't care about reproducibility of the response. For example a PUT will augment the data on the backend so when you run the test again the backend data will probably give you a different response to assert and fail your expected.

Due to the limitations of Cypress you end up using them both.

Cypress for the simple tests, and for the more complex case, e.g. opening tabs, testing your SSO login paths, I frame widgets, you end up using Playwright. I spend quite a lot of time to even fork Cypress to add support for testing WebKit browsers. Probably was quicker to write a Cypress kind of solution for Puppeteer/Playwright

We have Cypress tests that call our database directly and get information out, call 3rd party APIs to get information back, and call our APIs we've specifically created ourselves to help Cypress tests. It's pretty flexible; I'm just not sure how much this flexibility might bite us in the future.

One thing I didn't see mentioned is to just have some extra routes in /tests/* that are only enabled for tests to call or return data from arbitrary back-end code.

cy.exec() lets you run general system commands iirc. Istr seeding a database with it before running tests, I think if that command fails with Nonzero, the test would fail.