One of the dilemmas I have all the time is whether or not I should test the EPs directly (or resolvers for GraphQL), by providing a testing DB and checking against the expect results OR if I should just test service methods independently (requires more work to mock stuff around).
In theory, if each controller method (REST) or resolver (GQL) is tested, everything should be covered. Edge cases are a bit more rough, but not impossible...
To me, testing entry points and service methods would have different scopes. Testing service methods requires fully covered code and condition in every method, we can call it white-box testing. On the other hand, the scope of testing entry points or E2E testing is checking the request and response of the APIs whether expected or not. In E2E testing is like black-box testing, we don't have to know whether it's fully covered the service layer or not.
One of the dilemmas I have all the time is whether or not I should test the EPs directly (or resolvers for GraphQL), by providing a testing DB and checking against the expect results OR if I should just test service methods independently (requires more work to mock stuff around).
In theory, if each controller method (REST) or resolver (GQL) is tested, everything should be covered. Edge cases are a bit more rough, but not impossible...
Still figuring out...
To me, testing entry points and service methods would have different scopes. Testing service methods requires fully covered code and condition in every method, we can call it white-box testing. On the other hand, the scope of testing entry points or E2E testing is checking the request and response of the APIs whether expected or not. In E2E testing is like black-box testing, we don't have to know whether it's fully covered the service layer or not.
Good reference : methodpoet.com/unit-tests-vs-end-t...