You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FAM frontend unit tests were removed during a major refactoring. The team decided to transition to e2e tests for their efficiency and maintainability, as they provide broader coverage with less code.
This issue aims to restore automated frontend testing to integrate it into the CI/CD pipeline and align with organizational standards.
Tools to Consider:
Cypress
Currently used by Team Evergreen and Team Alliance, Cypress is a familiar choice but has known issues with flakiness and slower test execution.
Playwright
According to the internet, on average, teams using Playwright reportedly experience fewer flaky tests. It is worth exploring, given the importance of reliable tests. A comparison article is available here.
Others
Tools like Selenium or other alternatives could also be considered but may require further evaluation to fit team needs.
e2e Testing setup:
Another important consideration is the need for an e2e testing environment. Since e2e tests interact with the endpoint directly, they will perform CRUD operations on the database. This can result in an accumulation of test data over time, leading to maintenance challenges.
While we could delete test data at the end of each run, this approach is harder to manage and does not scale well. A more robust solution is to start backend servers connected to a newly created test database, which we already have available. Tools like start-server-and-test can help facilitate this setup, though other options may also be worth exploring.
Alternatively, we could intercept endpoint calls and return mock data to prevent CRUD operations on the database. However, I personally believe this defeats the purpose of e2e testing, as it requires more coding effort and doesn't fully test the "end-to-end" process. Team Evergreen attempted this approach but reverted to directly interacting with the backend due to similar concerns.
Acceptance Criteria:
Research the advantages and disadvantages of Cypress and Playwright (or other tools) for e2e testing, considering our team's context.
Investigate the feasibility of setting up a dedicated e2e testing environment, including backend servers and test database usage.
Explore the implications of intercepting endpoint calls versus directly interacting with the backend during tests.
Deliver a plan for implementing e2e tests.
The text was updated successfully, but these errors were encountered:
Description:
The FAM frontend unit tests were removed during a major refactoring. The team decided to transition to e2e tests for their efficiency and maintainability, as they provide broader coverage with less code.
This issue aims to restore automated frontend testing to integrate it into the CI/CD pipeline and align with organizational standards.
Tools to Consider:
Currently used by Team Evergreen and Team Alliance, Cypress is a familiar choice but has known issues with flakiness and slower test execution.
According to the internet, on average, teams using Playwright reportedly experience fewer flaky tests. It is worth exploring, given the importance of reliable tests. A comparison article is available here.
Tools like Selenium or other alternatives could also be considered but may require further evaluation to fit team needs.
e2e Testing setup:
Another important consideration is the need for an e2e testing environment. Since e2e tests interact with the endpoint directly, they will perform CRUD operations on the database. This can result in an accumulation of test data over time, leading to maintenance challenges.
While we could delete test data at the end of each run, this approach is harder to manage and does not scale well. A more robust solution is to start backend servers connected to a newly created test database, which we already have available. Tools like start-server-and-test can help facilitate this setup, though other options may also be worth exploring.
Alternatively, we could intercept endpoint calls and return mock data to prevent CRUD operations on the database. However, I personally believe this defeats the purpose of e2e testing, as it requires more coding effort and doesn't fully test the "end-to-end" process. Team Evergreen attempted this approach but reverted to directly interacting with the backend due to similar concerns.
Acceptance Criteria:
The text was updated successfully, but these errors were encountered: