What is E2E testing and why do we need it?

There are two types of tests that are commonly performed for web applications: unit tests and end-to-end tests.

We've seen unit tests in module 3 and 4 when we unit tested our API, and we'll be creating more unit tests for our frontend components in module 9.

In this module, though, we'll be creating E2E tests for our full-stack app.

Let's first talk about how E2E test work, and discover the difference between these and unit tests. That way we'll have a better idea of what we can accomplish with our E2E tests.

How unit and E2E tests differ

Firstly, let's define unit testing again so we have a basis for comparison.

So, the idea of a "unit" in testing, is a break-down of the code into small, easily testable parts.

E2E testing, on the other hand, is a type of functional test that lies on the other of end of the spectrum. Rather than testing units, we test the complete, integrated application.

For example, we may write an E2E test to test our registration process. The functionality behind this process is not fully represented by either the frontend or backend alone; it requires both to work together.

The other important difference with E2E testing is that it interacts with our application via the user interface, not the source code.

So a typical E2E test will navigating to the app in a browser, and then programmatically click on buttons, fill out form fields, etc, and then make assertions about the page state.

Tools

To perform E2E tests, you'll need a particular software stack. Starting from the bottom, the first piece of software required is a web browser.

Next, you'll need a browser automation driver. This is required because E2E tests don't use the regular browser APIs that we commonly use in app development and script with JavaScript.

Browser vendors also provide automation APIs with a lot of low level functionality that the browser automation drivers will abstract for us.

Finally, we need a test framework to run the E2E tests we write. The test framework will interface with the browser automation driver to execute and evaluate those tests.

In this course, we'll be using the Chrome browser for our tests. You can use regular Chrome for E2E testing, but if you're using a remote server or a development environment like Vagrant, it's better to use headless Chrome without the overhead of the graphical user interface.

The browser automation driver we'll be using is Selenium, which is the most common one available, and the testing framework we'll use is Nightwatch, which we'll be discussing in more detail shortly.

Unit and E2E test comparison

The last questions to address are: what aspects of our app should be unit tested, and what aspects should be E2E tested, and do we even need both?

The best way to answer these is to firstly understand that both unit tests and E2E tests have unique strengths and weaknesses.

Unit tests

The pros of unit tests is that they...

run fast, and

they're precise, allowing us to pin-point issues in the code right down to a specific function.

But the downsides of unit tests is that...

in large application particularly, it's time-consuming to write unit tests for every part of the code.

And not only that, but even if the unit test suite passes, it doesn't tell us if the application actually works in the hands of users.

E2E tests

What about E2E tests? What are their strengths and weaknesses?

The first main strength of E2E testing is that is allows us to implicitly test a lot of functionality all at once,

and a passing E2E test suite usually means we have a working application, which is the main goal of web development.

E2E tests have weaknesses too, though.

Firstly, they're usually slow to run. Since you have to boot the whole app on a server and then in a browser to test it, it commonly takes 5 or 10 mins for an E2E suite to run.

E2E can also be brittle. An inconsequential change, like changing a class on an HTML tag, can bring down the entire suite.

And finally, E2E tests won't pinpoint the cause of a failure. You'll know, for example, that the login process doesn't work, but you probably won't know whether it's a problem in the frontend or the backend, let alone which specific part of the code contains the bug.

Verdict

With the pros and cons of unit and E2E testing now understood, hopefully it's clear why the best plan is to use some of both.

There's an optimal combination where the weakness of one type of testing will mostly nullified by the strength of the other, giving you a fair amount of certainty that your app is working without overburdening your QA developers, and, at the same time, allowing you to quickly pin-point and eliminate any bugs that arise.

So that's all the theory we're going to cover. In the next video, we'll start setting up an E2E test suite for PrintBay.