Hello, I welcome to this talk on Ross to integration testing. If you are sitting with
the question, how do I automate my test? Great, sharpen your ears, we got you covered.
And yes, we do include full system integration test with Casibosimulations. Let's start
with preview touching on unit tests. So here's an example of using a G-test for a C++.
We define a test case with the test macro and sequently the digital test in the C-make
list. Linking libraries and dependencies is quite straightforward. Well, actually it's
not that straightforward because it's C-make but yeah, it's the same as for regular executables.
Now, if you've already done some robotics projects then you've probably experienced that
unit tests on the home. Yeah, it's not really sufficient like you want to learn several
nodes or in a simulator and so on. And that's what brings you to integration testing.
Now, Stu provides for this the fantastic launch testing package. And writing an integration
test is actually a quite similar to a Ross to Python launch file. I will start with defining
what to launch, which can be pretty much anything. Here in this example case, we launch
Casibosimulator and in addition some nodes to control a leg movements of or hexaport robots.
Next up, in our tests are active tests. In this we interact with the system and the test
through classic Ross's publish and subscribe as well as listening to process output.
And to finish, quite interesting, we do some post shutdown tests. These run after all nodes
and processes have finished and check whether everything is executed with good exit codes.
Next up is registering this test. You can also do that in the C-make list. And one thing
to take into account is that launch testing, it doesn't containerize the tests. And as
a result, the launch processes will communicate with, yeah, just about anything else running
on the same host. And a basic measure to avoid that, to at least isolate the Ross communication
is to use a unique Ross domain ID for each test. And using for example, the run test
isolated, that's trying to achieve exactly that. Now, to be honest, Ross II currently
doesn't yet offer a really solid approach for running tests in parallel, though projects like
test job coordinator are working towards that. So, great. We brought a bunch of code. What now?
Well, because we naturally believed all of this, it's quite straightforward. I would just
run call-com test. So, we start with the unit tests. Definitely integration tests. We
launch a Casibo. Okay, let's have a closer look. Okay, not looking too bad. It's moving. It's
working forward. So, now you have to know that each test saves its output into an XML file. And that
makes that tool slack, it's unit fewer, can easily visualize the output, print it nicely to the
terminal. And it even generates your fancy HTML web page. Great. I hope you all got an idea of
what you can do with the currently available Ross II testing tools. To finish these two
example repositories, implement everything discussed and shown. And in addition, there's the official
Ross II documentation, which offers the total covering both unit and integration testing.
Thanks for your attention. And I'll do it the last time, because I'm going to thank you for
there.