Using a mock back end for UI tests

Hi all,

I’ve been trying to field a lot of questions today about what to mock and what to not in relation to some user journey/acceptance tests in Cypress.

Our product automation is very immature and we are currently trying to implement a few testing frameworks to improve our product quality and confidence. I have no experience with using a mock backend, but have a team member who is very keen that we should mock as many interactions as possible with Wiremock.

I’m interested in getting some opinions from the MOT community - is it risky to use a mock for UI tests as we aren’t truly testing the connection to the back end? I understand that using the mock will mean our tests run faster and that we get feedback quicker, but i’m cautious about going too far. Is there a rule around when real interactions should be tested?

Many thanks :slight_smile:

2 Likes

Hi Claudia,
That’s an excellent question and one that I have encountered myself within my team.
It makes total sense that it feels like you are reducing test coverage cause you are!
But at the same time it’s the sane thing to do. UI tests lose their value the moment they become slow, flakky or hard to maintain and inherently any dependencies other than frontend will contribute to that loss.
At the same time this leaves you with an opportunity, to replace this coverage with lower level tests that are faster, cheaper and easier to maintain.
For every request you mock, this leaves a gap that can be covered with unit or API tests if they don’t exist already.

Saying that, it’s not always easy, some companies view end-to-end tests as reassurance and hesitate to move to testing layers that they don’t understand.

3 Likes

It depends on (:wink: ) what you and your team find important.

I have recently gone another way:
On one hand we have API based automated actions and checks for our back end / business logic.
On the other (running right after that) we have UI checks (connected to the same server with the same data) to open most windows and perspectives to check if those work (by containing data). NOT using every function in different variations.
We do not have full E2E checks, checking also the business logic by the client.

For automated UI checks it might be an alternative to have a server full with data. Then you even can check that the connection between client-server works. So you have a small server part, but do not include checks for the business logic here.

I’m very happy with this and would not go for mocking in my case.

1 Like

I’m a big believer in mocks and isolated component testing. It provides two huge benefits, the one you identified, faster tests(also as @stratos said ones easier to maintain) and also provides better information to the developer for defects. When testing single components it becomes much easier to track down bugs as you always know it’s part of that component.

This of course means that bugs caused by integration of components might not show up, as the tests may have similar assumptions as the developers and not catch edge cases in the transfer of data. However if you have written your test cases well for each component, it should be fairly easy to write ones that execute the same code but switch out the mock for a real system component. This allows you to test different components integration in isolation from the whole system, keeping other mocks for where they touch the system, and scale up to a full end to end test using essentially the same code and test cases at each level, just defining your suites differently.

You may not be able to make all tests part of a full system test but that’s ok. There’s almost never 100% coverage in testing so as long as you are making sure to exercise the full system in some amount, focusing UI automation on easier and quicker test using mocks to isolate that layer seems like the best idea for most products to me.

1 Like

I think it really depends on what your “UI” tests are for.

Sometimes UI tests are just to test the UI, in which case, mocking probably makes sense here.

If, instead, the “UI” tests are there to also be end 2 end tests or system level tests, then mocking doesn’t make sense.

I would probably guess that most of the time, a project wants a mixture of both tests at the system level to test the full system stack or at least large parts of it that may not make sense at a lower level AND have tests that exercise the UI that don’t really care about the system underneath.

I’m a fan of the Round Earth model of test strategy to have talks like this.

Depending on the requirements of your project, it may be that you need more or less of different types of tests, and thinking about what quality concerns you have will probably drive how much of the UI testing you should mock vs. how much to make system level tests.

3 Likes