[Discuss] UI Integration Testing of SPA

[link89]

I have a question about UI integration testing. The mock technique may work with traditional web apps. But for the modern SPAs I don't think it would be easy to do the same thing.

Take mattermost as an example. It an instant message application with a lot of states and event pushed based notifications. I am working for a similar app that I find it hard to use integration testing. Most of our cases are end-to-end level.

I am just wondering how to using integration testing technique for this kind of apps. How do you think about this? Thank you!

[NoriSte]

Hi @link89 Sure, UI Integration Testing applies perfectly to traditional web apps. Or, better, let's say to "traditional AJAX-based web apps" instead of "traditional web apps". It doesn't matter if it's a rich SPA or a traditional website, what matters is how the front-end communicates with the back-end.

Socket based communications or push notification based are different beasts and require manual implementations. I currently work on a big app, completely socket-based, but "unfortunately" the project is so huge that we have QAs and I should concentrate on unit testing instead of browser testing.

Anyway, I think that all depends on the dimension of the project, what I mean:

• (if it's small or replicating the server logics is too hard) go for E2E testing, and...
• (if it's mid) ... try isolating the front-end modules and test them in isolation
• (if it's huge) probably you need a QA team and a good synergy between the development team and the QA one

I won't deepen the topic right now because I couldn't test it on a real project at the moment, I'll probably return on the subject in the next 6-9 months.

Let's try to have someone jumping into the conversation @muratkeremozcan @goldbergyoni

[muratkeremozcan]

We have a mid size Angular app on the front end, but the back end is vast with a Node api interfacing a plethora of Go Lambdas at one layer and on a deeper layer controlling hardware. For this app, the dev and test team are one; no separate test team.

With a complex app like this, you cannot get away with 💯 ui-integration tests. But, they can do two great things for you.

UI integration tests can reduce the e2e needed, because some fault causes might be UI isolated; it cannot fail because of the back end. For example a feature that filters data; you just need the backend be to provide any data there. You can test the back end in isolation, that it responds to GET requests. But for the front end, UI integration will be good enough for 90% confidence.

The other perk could be test isolation in deployments. Let's say you change UI code, do you want the tests to fail because of back end issues immediately? No, you want a constant back end first so that you can get working UI code in a feature branch. Later when merging the feature to deployment, then you want that test to run with the back end considered. Here you can flip those tests. Check out this presentation for an example https://slides.com/muratozcan/how-siemens-sw-hub-increased-their-test-productivity-by-38-using-cypress#/3/1/0 .

Having said all that, some of our functionality is very back end reliant and the back end is not tested well. Ideally they would have abundant contract and integration tests, which would give us enough confidence with a stubbed network / ui integration test. Some of these cases we don't even flip the test between ui-integration and e2e because it never fails because of the UI, always the back end.

Testing is always a matter of cost vs confidence. Sometimes you can get away with low cost and high enough confidence. That's the spot for ui-integration tests.