What's the difference between a UI test and an E2E Test? And What's the benefits of each?

Our team is considering starting testing based on user scenarios. So, we are picking a E2E framework.

Searching for UI test lead to the following:

So, I found this this

It says

UI testing: user interface testing. In other words, you have to make sure that all buttons, fields, labels and other elements on the screen work as assumed in a specification.

GUI testing: graphical user interface. You have to make sure that all elements on the screen work as mentioned in a specification and also color, font, element size and other similar stuff match design.

Functional testing: the process of quality assurance of a product that assumes the testing of the functions/functionalities of component or system in general, according to specification requirements.

E2E testing: it needs for identifying system dependencies and ensuring that the right information is passed through multiple components and systems.

I don't get the difference between UI Testing & E2E Testing.

I wrote UI Test Code in Android Studio. And I need to write a code for each and every click and view, etc. I feel why do we need this? I'd rather test with my finger directly and dynamically.

Let's start by looking at what the difference is between E2E (end to end) testing and UI testing:

End to end testing is checking the whole system / product behaves correctly when used in the way it will be deployed.
UI testing ensuring that the UI works correctly.

Essentially UI testing is focusing on the UI component of the product. It would be entirely appropriate to do this testing with a mocked backend to avoid needing to run the entire system to check the UI.

There is an amount of overlap between UI testing and E2E testing. I.E. if you test a form in UI testing I would also expect that form to be tested in an E2E scenario. The main difference would be the coverage, the E2E test would try to cover the scenario which may be one use of the form. Where as, the UI testing would cover all the things that the user can do with the form, including entering bad data.

One of the problems with E2E testing is often when a test fails you need to spend some time working out which component has caused the failure. By having tests for each component (including UI testing) there should be a corresponding failure in the tests for one of the components.

Imagine that your E2E test has failed because the login button has disappeared from the UI. Your E2E test will say user cannot log in. Is that because of the UI, the API, the credential store (e.g. database), connection to external service when using SSO (e.g. LDAP)? When looking at the UI tests it will also say user cannot log in, but now you know it's a UI problem.

I wrote UI Test Code in Android Studio. And I need to write a code for each and every click and view, etc. I feel why do we need this? I'd rather test with my finger directly and dynamically.

As with all testing the depth you go into with each type of testing is a decision based heavily on your needs. There are many cases where the manual testing you describe is entirely adequate, typically because the system is not safety critical and the cost to fix issues is low. However, if the cost of fixing issues is high, or the system is safety critical you might wish to invest in writing tests for every click or view could be useful.

Recommended topics

Hot tags