How do you initially script/debug the long automated end to end UI tests?

Question

Background: In the long end to end UI automated tests, one needs to execute multiple times during initial scripting/debugging and later for maintenance/fixing which takes a lot of time as a test might be navigating through multiple pages to complete a user journey/transaction.

Problem statement: Is there a way where one can short-circuit these long executions and quickly "test" these tests for some small fix/change in a faster way like sub-tests/unit tests?

Note: I am sure , I know about unit tests and test pyramid in general :). The question is more about end to end tests which are generally long as they are well end to end , covering an business flow/transaction so how ppl test them without running again and again .What are best practices ppl follow/discovered to debug/ update/fixing of them to save debug/update time in maintenance.I used the word 'unit test' in the sense how do you test them in parts or some other faster way.

Answer 1

I believe your question is one I have asked and solved in a few organizations.

Many organizations have multi-part form workflows to gather information.
This leads to UI testing which is slow because to test anything on page J you always have to go to A,B,C,D,E,F,G,H,I to get to it. Every. Single. Time.

This leads to horrendously slow UI tests. Also, as UI tests are inherently fragile this can leads to a slow running test suite with frequent intermittent failures. Obviously not good but this is almost the norm in many organizations.

The solution I have used is "hack the session".
Basically when you are navigating through multiple pages/forms you have a web session that is also used to determine which pages to go to, which page next, etc.
To "hack" this means interacting with the session life span and setting attributes that will let you visit a specific page. How to do this will depend on the language and tools you use but this is the basic approach.

How well you can do this with a given application will depend on the details and how much information from one page or form 'affects' other pages and forms. In practice, I have found that multi-page form are surprising independent, e.g. gathering demographics, gathering contact info, gathering school info, etc. are all quite independent. Also if you have database access you may be able to correct 'seed' the specific page you want to test, without it you might not. ymmv.

Answer 2

A possible solution to avoid lengthy or expensive end to end tests is to use contract testing. This is where you test the contracts between the various parts of your system to gain more confidence about how they will integrate. Once you have a reasonable level of confidence you can then run the more expensive tests with less chance of reruns.

Pact is well evolved framework for contract testing https://docs.pact.io/

Answer 3

Unsure what you are trying to ask as you seem to have already answered your own question. Given the fact you edited the title which already nicely gives you the answer.

Consider looking into the testing pyramid. You should aim to have lots of quick unit tests, a good amount of slower integration tests, and a small amount of slow end to end tests. If your E2E tests are taking too long that its slowing production then they go against the agile process. Having a solid collection of unit and integration tests will provide much quicker feedback without hindering productivity.

Answer 4

The best way to speed up E2E tests is to run them in parallel. The most of modern test execution frameworks support parallel run. However you should also consider possible conflicting cases which might introduce inconsistency.

Ideally you need several completely isolated environments running in parallel for each test. However if you're in a tight budget you can think out your test logic to minimize the probability of test conflicts.

P.S. - running different tests in parallel without segregating the environments might be even the better case by the way since in the real life E2E flows are performed by different users in parallel so that you might catch even more bugs in that case.