I think the right approach is to build from the ground up for testability both on unit-test and integration-test. But one has to be very careful how to structu

I think the right approach is to build from the ground up for testability both on unit-test and integration-test. But one has to be very careful how to structure the pieces/components. For example: Do not write extensive unit-test on the UI but definitely have extensive Selenium tests for the UI _library_ (if you are a library builder). If you are a library user, assume the UI works as advertised and attaching/removing event-listener can be considered "configuration" type of code: test it once to see if it is configured properly and that's it! If the SPA uses some sort of MVC/MVP, I'm hoping I can: 1. For unit-test - unit-test individual M,V,C,P, Service, Helper, Model Validators, etc - ability to mock different aspects 2. For integration-test - ability to construct the whole thing (MVC/P) including the back-end, mock the View, and start controlling/simulating the code execution from the Controller/Presenter The integration test can cover more than the unit-test to the point almost close to Selenium type of test but not as brittle as Selenium.