Two brothers examine the pros and cons of UI testing

Based on their different experiences in Partner Solutions and Zalando Media Solutions respectively, we speak to frontend developers, Vadym Kukhtin and Oleksandr Kukhtin about their opposing opinions on UI testing.

The Case Against UI Testing - Vadym

**TL;DR It depends on preference, but I believe that UI testing isn’t required in every instance **

In my experience, it is a sisyphean task to force developers to write even basic Unit tests, nevermind UI and E2E. Only Spartans led by Leonidas can achieve UI and E2E testing.

Of course, the case for UI testing is more complex than a simple “good vs bad” dichotomy. For example, the scale and scope of the app should be taken into account. If the app is small or short-term, most probably UI tests aren’t required. If it’s a monster project that needs to be covered as much as possible, then unit and E2E tests are required.

In the real world app, any interaction should change some state of the app, whether it’s a click, hover or any custom event. With unit tests, the developer can test internal component or service functionality, and with E2E the developer can test common component interactions and connections to third-party services, and API and backend functionality.

Example:

• Use case: User should be able to login using OAuth and see “Hello” board.
• App:

• Test case:
• Unit test: Checks which functions inside LoginComponent were triggered when the mock user clicks on the “Login” button. If “login()” function is triggered and the router state changed to “/hello-board”, we can discern that everything is working fine.
• E2E test: Checks if the user really clicked on the correct button, if OAuth returned the correct data, and if current location state in the browser contains the “hello-board”

This process can be incredibly time consuming, with developers spending time writing the tests and mocking all dependencies. For small or short-term apps, we have to ask ourselves: is the time worth it?

My answer would be no.

The Case for UI Testing - Oleksandr

TL;DR In most cases I think we don’t need to write UI tests.

Let’s start with a small illustration. You start a new project and a month later have a nicely working app. You then decide to change one component in your structure. It is only UI component, so you know, that logic has no changes. The change itself works, but now the app has some of errors: it looks like you forgot about some style changes and your component now looks awkward. So, you fix the styles, deploy the changes, sit back and relax. But now, you have unwanted style issues in other component. So you again do the same thing and deploy the changes. Ideally, UI tests can identify this kind of problems.

Like most things in life, UI tests has advantages and disadvantages. Some argue it takes too much time, but this time can be considered an investment, safeguarding against any unwanted games of “tennis” as seen in the example above. Testing UI helps us better understand our code, and what actually it should render.

Yes, testing is complicated. Complex UI logic is pretty hard to test, but not inconceivable. Problem appears here: the process has so much troubles for the advantages gained: you need to write a lot of tests, but in result even small changes (that often happened with UI) force to rewrite bigger part of it.

In Conclusion The biggest takeaway from our discussion is that UI testing cannot be simply filed away under “good” or “bad”. In some circumstances – such as small apps or short-term projects – testing may not be the best use of time. In others, testing is a must for maintaining the integrity of the components and saving time in the future.

Got an opinion on UI testing and want to bring it to a dynamic team? Get in touch. We’re hiring.