My gut feeling is to concentrate on automating the backend API first.
Unit tests are good and necessary, but they don't give me high confidence that the system as a whole functions. Some of the most insidious bugs happen when different parts of the specification interact in ways the writer did not think about, and unit tests tend to capture only a very &...
TL;DR: you will have overlap between E2E and API integration test cases, in terms of the same endpoints being exercised in both and that's OK - it helps you figure out where the problem is if (...when) something goes wrong.
When working with a codebase that doesn't currently have comprehensive automated testing, start with the E2E(/functional/UI) tests. Why?
You should always pick tests carefully when it comes to test automation. :)
One of the reasons, as you said, is overlap (and with that, execution time and robustness).
An example to clarify:
Your API has 10 endpoints which might return several different error messages each.
Don't test each error as a UI test: this will take up lots of runtime and will also ...
There is no concept of overlapping testcases in different test levels,
Both are completely isolated
Just because API works fine you cannot guarantee UI works fine.
Imagine all your API tests passing but user not able to use the UI , Imagine all your UI working due to cached information but actual backend is failing.
Ensure more low level coverage like unit ...
There is no need to test the same thing with API and UI tests.
Start with API (keeping in mind the test pyramid), provided code is sufficiently covered with unit tests, and automate certain e2e scenarios that would cover cases not covered by individual API.
The file path should be relative to class path , try