Closed xela-95 closed 5 months ago
Attention: 5 lines
in your changes are missing coverage. Please review.
Comparison is base (
dab8a73
) 83.19% compared to head (404f77b
) 83.36%.:exclamation: Current head 404f77b differs from pull request most recent head c619175. Consider uploading reports for the commit c619175 to get more accurate results
Files | Patch % | Lines |
---|---|---|
plugins/clock/Clock.cc | 80.76% | 5 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@traversaro I tried to develop a first basic unit test for the clock plugin, here:
The unit test instantiates a gazebo server fixture and reads the /clock
port after a certain number of simulation steps have been ran. Then it checks whether the elapsed simulation time received on the port is the one expected (number of timesteps times delta T).
Next I will try to add test to check other expected behaviors, like the pause and reset of simulation.
In commit 5acde4f08c7066d4afbf20918ab7b7df9a16cac9 I've implemented the ISystemReset
interface. In this way, every time the user requests a simulation reset through Gazebo UI this method is called instead of destructing and re-constructing the plugin with the consequent closing of the yarp port. Now for a subscriber to the port the reset is transparent and it will just see the simulation time starting back from zero.
Unfortunately I've been not able to implement a unit test since the Server object does not expose a Reset()
method that I can use to inject such event.
Some issues and PRs talking about reset:
This PR adds to the gz-sim-yarp-plugins a clock plugin, with the only basic functionality of writing the current simulation time on the yarp
/clock
port.Closes #60 , #73