gtagency / pyrostest Goto Github PK

View Code? Open in Web Editor NEW

3.0 7.0 2.0 107 KB

A library for testing ROS systems using python test frameworks

License: MIT License

Python 90.97% Shell 4.49% CMake 4.54%

ros unittest python-framework rostest

pyrostest's Introduction

🔥 pyrostest 🔥

The most 🔥 lit 🔥 ros testing framework.

Pyrostest is a (more) pythonic framework for writing ros tests.

Why pyrostest?

Writing rostests and rostunit tests is annoying. You have to write launch files for all of your tests and then do strange things in your unittests and then somehow the rostests and unittests will communicate. To be honest, I never could get rostest to work. So I built something better. pyrostest allows you to test your ros nodes in pure python, no need for xml files.

Usage

Here's a minimal example of a pyrostest test. Assume you have a ros node, add_one in the ros package pkg. The node subscribes to input, a Float64 message, and published to output, another Float64, it adds one to the input and publishes it. This would test that functionality

from pyrostest import RosTest, launch_node, mock_node
from std_msgs.msg import Float64

class TestAddOne(RosTest):
    @launch_node('pkg', 'add_one')
    def test_add_one(self):
        with self.mock_pub('/input', Float64, queue_size=0) as p:
            with self.check_topic('/output', Float64) as r:
                p.send(Float64(7))
                assert r.message.data == 8  # or self.assertEqual

This code will spin up an isolated instance of Roscore, as well as all of the nodes needed for testing. It will then publish the float 7, and wait until the data has been recieved, and assert about its value.

pyrostest's People

Contributors

Stargazers

Watchers

Forkers

hello-binit russ76

pyrostest's Issues

Fix the format bug in NoNode

https://603-53988135-gh.circle-artifacts.com/0/tmp/circle-artifacts.2GGpoDT/simulation.txt
gtagency/buzzmobile#211
https://github.com/gtagency/pyrostest/blob/master/pyrostest/ros_test.py#L155

Clean up naming conventions.

There are some bad naming conventions throughout. We should improve that.

Integration with C++ coverage analysis

How can one integrate coverage analysis (e.g. gcov) for C++ nodes tested with pyrostest?

Fix flakyness

Despite prior work, still some flakyness. Source is

dist-packages/rosmaster/master_api.py:208: xmlrpcapi(api).publisherUpdate('/master', topic, pub_uris). pub_uris is an empty list. This publisherUpdate method is an autogenerated method from an xml rpc api somewhere else in ROS, so debugging this is mildly annoying. See this error message:

[rosmaster.threadpool][ERROR] 2017-05-14 18:56:01,541: Traceback (most recent call last):
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosmaster/threadpool.py", line 218, in run
    result = cmd(*args)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosmaster/master_api.py", line 208, in publisher_update_task
    xmlrpcapi(api).publisherUpdate('/master', topic, pub_uris)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1233, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1587, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.7/xmlrpclib.py", line 1273, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1301, in single_request
    self.send_content(h, request_body)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1448, in send_content
    connection.endheaders(request_body)
  File "/usr/lib/python2.7/httplib.py", line 975, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 835, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 797, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 778, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python2.7/socket.py", line 571, in create_connection
    raise err

I believe what's happening is that add_one is publishing an updated value and the nodes that subscribe to it don't exist/have unregistered themselves for some reason.

Add tests

Provide py2/py3 compatibility.

Its likely that ros will one day move to py3k compat, we should get there sooner. I don't think there will be a lot of work to enable that, and if we do we can set bdist_wheel to true/1 in our setup.cfg, which would be a nice-to-have.

Publish on pypi

Readme needs more :fire:

Add 🔥 to the readme, because its lit.

Determine best way to test pyrostest.

There's a bit of a conundrum with testing this. We'll need CI, but I think the best way to test this will be to create a rospackage for testing that this deploys when we want to actually test, which is horrendous and mildly frankenstinian, but I can't think of anything better.

To be more concrete, a tests/ dir with tests and also a rospack subdir which contains a ros package that is deployed to catkin_ws by our CI script.

Improve all sleeps

Realistically, there should be no arbitrary sleep(n) in the codebase, every sleep should be in a loop until some event.

fix listener.py and subscriber.py

They currently rely on a directory, we should fix that.

Add some more robust tests

The tests currently in test/pyroestest/test_system.py won't give useful error messages, and may pass for the wrong reasons. While they're a good smoke test, we should add another set of tests that follows a pattern like

class TestSystem(unittest.Testcase):
    class InternalTester(unittest.TestCase):
        @decorators
        def test_function(self, stuff)
    self._testcase = InternalTester
    def test_testcase(self):
        with self.assertRaises(CorrectException):
            self._testcase.test_function()

Some more meat to it than that (correctly running the test contextually) but that's the idea.

Determine a good abstraction for simulation tests

It'd be interesting to have some abstraction that handles some of the simulation testing needs. For instance, making sure that a robot reaches a certain region of the world within some timeout, or making sure that a robot doesn't touch obstacles when moving, etc.

This is going to warrant a considerable amount of discussion, since getting this abstraction right, and in a generalizable way (that works for more than just buzzmobile) is very important.

Because testing the framework currently relies on our experience developing buzzmobile, I'd say this issue is somewhat blocked by gtagency/buzzmobile#183. Until we have actually made worlds and scenarios with pass/fail conditions, it'll be hard to determine a good abstraction.