Our current workflow for writing unit tests uses the unittest python library and ROSTest to manage our unit and system tests. This guide gives some best practices.

Create a python file with a class following the naming format <name>Test and ensure it inherits from testcase

ex:

class PixhawkTest(unittest.TestCase):

this class will house a set of tests in the same category, in this example it will be pixhawk unit tests. To write a test case, make a function with the naming style test_<name>. In these test cases, you are free to do what you like to perform unit tests. In order to assert, use self.assert<type> specifics of these can be found in the unittest documentation, but for example you can check equality with

self.assertEqual(vertical_rate, 1550.0, MESSAGE)

It is highly recommended (and required for PRs) that you have good messages that detail what the value should be and what it actually is, that way in case of failure the user can easily understand what went wrong.

ex:

self.assertEqual(vertical_rate, 1550.0, "PIXHAWK NODE: RC rate does not match sent rate, was {} should be {}".format(vertical_rate, 1550))

as of now these tests should be located in the same package as the nodes they are unit testing. In that package you will also need a *.test file to run the test. If you're just doing unit tests, the convention is to have it be named sanity_checks.test. I highly recommend looking at the sanity check file in wolf_serial to understand how to write these files (they are just normal launch files with a new "test" tag).

to run these tests use the command rostest <PACKAGE_NAME> <.TEST FILE>

ex:

rostest wolf_serial sanity_checks.test

Writing system tests is similar to unit tests, but there is a more strict guideline on how these tests should be written for Seawolf 8. The following elements should be considered when writing a system test

• target: this is what the system test wants the robot to do, for example if it is a depth test, this would be the target depth. It is easiest for the target to be some sort of natural number, as those are the easiest to quantify and fit into the described system.
• tolerance: how close to the target is considered "passing", this is a percentage number i.e 10% tolerance means you can be within 10% of the target and still be considered passing.
• hold time: how long the test should hold stay in tolerance of the target in order for it to be passing.
• time out: if the goal is not reached in this amount of time the test is considered to be a failure.

these values should be easily tweakable at the top of the test file. To see a good example of this please see test_pose.py, which shows how to write simple versions of these system tests.

writing a launch file for these tests is more complicated. For now the recommendation is to copy what is in test_seawolf8.launch and then add in a test tag at the end of the file that runs your system test (a good example of this is test_pose.test). This can be launched in a similar manner with rostest <PACKAGE_NAME> <.TEST FILE> however this will not work in isolation, since the simulation software needs to be running. It is recommended to use the test_start.sh file to start your tests, and just change the rostest line to change which tests are run (a more elegant and permanent solution for this will come soon)