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