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
Investigate and document how we should integrate Cypress into our current EtE infrastructure.
Scope
Questions to answer:
A lot of tests require a specific island state. Registration test requires no registered users, report tests require events to be gathered etc. We need to agree on what's the best way to test UI.
Our options:
a) Do integration tests and inject/mock the state. For example, to test the report we would have to inject events. The downside of this approach is that we'd have to remember to update the mock data if events change, we have to maintain this mocking infrastructure and this approach is not actual EtE. The upside is speed.
b) We run EtE tests relevant to the current state or set the required state via user actions. The downside is speed and tight coupling to the actual island process. The upside is that we don't have to worry about our mock data getting outdated and we test what the user does, so it should give us more confidence.
c) Some combination of both?
d) Neither, just do manual tests?
e) Something else entirelly?
How do we need to change our pipelines? Will Travis run any tests? What tests will Jenkins run? What tests can we run on demand locally?
Output
An issue(s) that has a list of tasks to achieve the testing infrastructure we want that includes UI tests.
The text was updated successfully, but these errors were encountered:
VakarisZ
added
the
Spike
A small chunk of work with the objective of gathering information.
label
Mar 4, 2024
Spike
Objective
Investigate and document how we should integrate Cypress into our current EtE infrastructure.
Scope
Questions to answer:
Our options:
a) Do integration tests and inject/mock the state. For example, to test the report we would have to inject events. The downside of this approach is that we'd have to remember to update the mock data if events change, we have to maintain this mocking infrastructure and this approach is not actual EtE. The upside is speed.
b) We run EtE tests relevant to the current state or set the required state via user actions. The downside is speed and tight coupling to the actual island process. The upside is that we don't have to worry about our mock data getting outdated and we test what the user does, so it should give us more confidence.
c) Some combination of both?
d) Neither, just do manual tests?
e) Something else entirelly?
Output
An issue(s) that has a list of tasks to achieve the testing infrastructure we want that includes UI tests.
The text was updated successfully, but these errors were encountered: