Some relevant guidelines:
The goal is confidence, not coverage. If you have good coverage with well-written unit tests then a tiny number of high-level tests can be enough to have confidence that the overall system will Just Work™.
Having both unit and integration tests for the same functionality is a waste of time in terms of writing the tests, maintaining ...
I would consider the whole idea of verifying such logic from the UI perspective as a bad practice. See info on test pyramid.
If you need to test the calculation logic of your service - you can do that on the unit and/or integration testing level, which would be much easier to do, since you will be free from external dependencies in that case.
You can make a call to TestRail's endpoint add_result_for_case.
Example in Java:
Map data = new HashMap();
data.put("status_id", new Integer(1));
JSONObject r = (JSONObject) client.sendPost("add_result_for_case/1/1", data);
You can find the definition of the endpoint here.
You can find the complete documentation here and some extra ...
I used to write integration tests in Postman and after a couple of tens of requests, it became very difficult to maintain. Mostly because:
accessing other resources like a DB was hard
it was hard to separate test data from actual requests
it was a bit harder and definitely more criptic to use a data driven approach
you still need to use the GUI interface in ...
In overall it looks more a question regarding the code-based vs tool-based testing.
And for the low-level, technology facing tests, such as integration tests, the code-based approach would give you:
A little bit more overhead while writing the tests. You'll have to write the code itself (obviously), and potentially manually write mocks for the components ...
I found an solution for comparing larger objects (specific to my case, since it's actually part of FluentAssertions).
From the documentation, it compares with a recursion of 10 levels and it it's used like this:
I submit that a best practice to compare large objects is ...
Consider not using 'code coverage' as your metric
Because systems and integrations have different issues and failure points it is hard to measure code coverage across systems.
Code coverage, even for unit tests is a very rough guide and in my experience ends up, in reality being:
You have to meet a metric, say 80% to get your code merged. This leads to low ...
The way I see it is that integration tests are actually about integrating real stuff, not mocking.
It makes sense to mock other components in your unit tests, because you are focused on your component you're implementing, so you want to filter out yet another complexity in the form of those other components, or those other components might not be implemented ...