Preface - Reactive/Passive testing

• e2e testing is very time-consuming to write, for example, this bug can be fixed in under 10 minutes but it takes me 3.5 hours to write the proper e2e test
• We want to maintain the high development speed
• We mainly want to focus on stopping regressive, user-facing bugs happened again
• We use unit-testing to

Solution

• Instead of demanding e2e test on releasing feature, we demanding e2e test on bug reports. For every user-facing bug about pipeline-builder demand proper e2e testing. PM and FE can flag the corresponding bug with the label test-needed.
• If PM wants to further highlight the urgent test-needed bug, I suggest we add a state Request Testing for better tracking and managing. This is primarily for safeguarding.
• Once every ticket is flagged by one of these two states, FE need to embed proper e2e testing in the PR
• We can be flexible about the bug fixes, for example, we can fix the bug first then add the corresponding testing in the next sprint if the time is limited (This is also the reason I want to add the Request Testing
• We mainly rely on e2e tests to guard regressive bugs and use unit testing to guard fundamental stuff, such as auto-generated forms.

Where we use unit testing

• ✅ Helper function should have unit testing
• ✅ Auto-generate form should have unit testing for it’s component and functionality
• ☑️ Smart hint system should have unit testing for it’s component and functionality

Where we use e2e testing

• Bugs that is crucial for properly user flow should have e2e testing to guard it from re-surface again