With Angular most of the functionality of simple components or artifacts of the state management can be tested with Unit Tests.
However, when testing multiple artifacts at once, the
TestBed definition can take a big amount of work.
Also considering, that not the real runtime modules are used in unit and module tests, it might be better to write short and concise Cypress tests for this functionality.
Testing issues with timing and interaction between many artifacts is also quite hard to implement as a unit test.
All in all, cypress testing should not be exhausting.
As a general rule only happy path and smoke tests should be implemented.
Testing workflows with many actions can lead to increased instability when encountering browser hiccups.
Split tests into individual specs when possible.
Every test should be independent of other tests.
So whenever a test is including a modification operation, it is best to create an individual user first.
When testing functionality that needs to setup specific demo data first, do not create it via the user interface.
Instead write stable REST API helper methods, that can set up data faster via the API when the test starts.
We introduced the PageObject Pattern with the motivation of separating business-features from technical background.
So do not use HTML-specific selectors or exposed cypress functionality in tests if possible.
Also do not hide too much actions with the PageObject Pattern.
As a rule of thumb, whenever the user triggers an action, it should be represented by a line of code in the spec.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.