@piyushsingariya just copying over here part of our discussion for posterity hehe
Cypress is more UI tester right(I started contributing with that here) and it involves the mocking response thing,
but here we’re interested in actual testing of running meshery-server.
So I am confused how this could be achieved with cypress
Good point @Piyush Singariya, keep in mind that tests under /ui/cypress/integration/e2e folder will not mock the backend response, they will hit server
the mocking happens (should happen) only for tests under /ui/cypress/integration**/integration** folder
it supports both Frontend isolation AND Fronted interaction with Backend
hmm, I like what I am reading…
You’ll see there’s a specific job to run e2e tests:
Although @Piyush Singariya probably you have a good point in the sense that there could be some conditions that don’t fulfill on certain PRs which make these tests not to run, can you share link to PR where what I shared above does not happen please?
I see, when all files are under ‘/mesheryctl/’ folder, our ci.yaml workflow will NOT run so no cypress integration nor e2e tests get triggered for that specific PR:
I don’t consider this as a big deal because changes in mesheryctl are irrelevant to both the UI and meshery-server.
So it’s better to not run an extra workflow.
Wouldn’t it make sense to ensure meshery server installed by mesheryctl works as expected from the user perspective? I imagine it “only” packages and exposes server but… it also does some configuration steps right?
I don’t feel convinced to run that GH job for mesheryctl folder. because these E2E tests are to test UI behavior and the meshery-server.
Both Unit/Integration Tests in Golang are equivalent to e2e tests for mesheryctl. Given we mock different types of responses from meshery-server.
I don’t understand this part