I joined a full stack automation team recently. There are some selenium tests for the frontend and APIs aren't automated yet. My question or thought process is should I pick the test cases carefully to avoid any overlap between frontend selenium and backend Rest assured based tests? Or it's common to have overlapping test cases in this scenario.
The backend APIs are consumed only by web, there isn't any mobile or other teams that consume them.
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:
Another reason to think about which cases to automate is simply that not every automated tests is as useful or cost efficient in the long run. I advise you to look on YouTube for Angie Jones' presentation on "Which tests should we automate" - also see https://slides.com/angiejones/which-tests-should-we-automate#/20
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 test and API test , this ensures that you will have faster test execution and build feedback. This will also ensures faster debugging as your tests will be more focused on component or feature.
In UI test actual business flow and error handling tests
In each test level we have different test scopes.
Unit test;
We don't test the business flow but the component and functionality
Integration Test
Integration with other components , how stable is the integrated subsystem to be able to be used to extend with higher level components . Like API with UI
System Test
Here you test Usability , user interactions , visual regression , business logic and flow.
So there are no concept of overlapping tests in different testlevels
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?
Automating the app through the UI workflows helps build empathy for the users - what are they using this for, and how do they do it?
These tests let you check the software actually delivers the value it's supposed to; your users don't care about API calls or functions! Note that this would be different if your API was a product in itself, not just consumed by the web client.
From a more technical testing perspective, lower-level tests will likely require some changes to implement (e.g. to introduce appropriate boundaries to test at); code written without thinking about testing is often difficult to test. You need the higher-level tests to give you confidence those changes were made correctly.
This will likely lead to a place where you have too many E2E tests, characterised by overly long test run times, but you can now start pushing tests down the stack to integration and unit tests. Focus on maintaining a set of key workflows (this can be a good conversation with the product people in your team - does everyone know what the key workflows are?) at the E2E level, then push the less important paths and repetition to lower-level tests.
In terms of the API tests specifically, there will be a lot of overlap; your E2E test cases should exercise every endpoint at least once (if not, think about whether the unused endpoints can be removed). This overlap is fine, because now if an E2E test fails but the relevant API tests pass you've localised the issue to the UI. But there will be things that are hard to test through the UI. Commonly these are the unhappy paths, for example:
you probably have validation of inputs at the UI level that prevents the request getting made if they're invalid, but you should still be testing server-side validation; and
you probably don't have links to missing resources in the UI, but still want to test 404s.
Similarly there are things that are hard to test through the API, and require a lot of setup and teardown; in this case, push down further to unit test the service/business logic layer (I would not recommend unit testing the controller/transport or repository/persistence layers; these tend to be largely boilerplate, if they have a lot of logic it's probably in the wrong place).
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 "local" view on the specification.
Say in one class null values are rejected as invalid, in another class null values are interpreted as an empty list. Odds are that the unit tests for each class faithfully test exactly that behaviour.
GUI tests are good and necessary, but they are also hard if they are supposed to replace manual testing. There are so many different devices, so many different browsers. An automated test which tells you that the system is "good to use" on many devices is a lot of work. (That might be a slight bias on my part because of my backend background, and it assumes that the business logic is in the backend ...).
API tests represent the "contract" of one subsystem against another. It might be difficult to generate test data which is both realistic and exhaustive, but once you have that you can have some confidence that the backend does what it is supposed to do.
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.
