[Piyush Singariya]
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
[Piyush Singariya]
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:
@Lee @navendu Regarding the skipping ci.yml workflow when only modified files are from /mesheyctl/ folder, shouldnât we run cypress integration and e2e tests as well on those scenarios???
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
