...
If you have access to the application source code, you should generate the static coverage file using Jtest or dotTEST in .xml or .data format if at all possible. The method has several advantages, including containing metadata about user classes, methods, and lines, as well as supporting showing source code annotated with coverage data when viewing coverage results in DTP. It also improves Test Impact Analysis, as static coverage generated this way provides for more precise analysis so tests will only be flagged as impacted if they traverse any methods that have been changed. While you can use TIA with static coverage generated from application binaries, TIA results will be broader (since analysis is done at the level of classes) and some tests may be flagged as being impacted when they don't need to be. See Application Coverage (Jtest) or Application Coverage (dotTEST) for more information on generating static coverage files with those tools.
...
Attaching the Coverage Agent to a microservice allows you to enable collecting dynamic (runtime) coverage for it. Typically, this is done as part of an automated deployment process coming from a CI/CD pipeline. As part of this process, you will have the opportunity to review the agent's settings in the agent.properties file; while doing so, ensure that the include and exclude values that are used are the same as those defined in your static coverage process.
Attaching the Coverage Agent for Java
...
Once started, you can check that the agent is running by going to the agent's status endpoint at http://<HOST>:<PORT>/status, where <HOST> is where the microservice is running and <PORT> is specified in in agent.properties; by default, it is 8050.
...
Once started, you can check that the agent is running by going to the agent's status endpoint at http://<HOST>:<PORT>/status, where <HOST> is where the microservice is running and <PORT> is specified in in agent.properties; by default, it is 8050.
...