Client / server question

[Kenneth Ekman]

I am working on a DBus server implementation, and need to unit-test this in some way.

I found this method to create a local DBus test server running just for my tests:
https://developer.gnome.org/gio/stable/GTestDBus.html

and thought that would be a better way to make my unit tests than the (normal) way of stubbing and manually calling the server methods from test scripts...

Normally we use the check framework for unit tests, so I'd like to do so here too, but it hit me today that check normally runs in just one executable, so maybe checking the test coverage on the server side is not possible?

[Branden Archer]

For unit tests it's generally better to stub things out rather than having many moving parts. Isolating components and testing each component, or unit, individually will make simpler unit tests.

That aside, you could use Check to create the tests you are looking to write.

check normally runs in just one executable

This is not always the case. If Check is run so it uses fork(), then the unit tests will run in a separate process, and progress is monitored from a parent process. Check is only single-process if configured to be that way.

Check tests can be configured with setup and teardown functions that could create any resources you want, which could include starting a process (e.g. a server). The setup would create it and the teardown would destroy it.

Here are relevant docs:
https://libcheck.github.io/check/doc/check_html/check_4.html#Test-Fixtures

so maybe checking the test coverage on the server side is not possible?

Do you mean using code coverage with gcov? That should be possible.

[Kenneth Ekman]

The tests are already running. It is only the grov parts that i have problems with.

[Branden Archer]

The gcov stuff should be independent of libcheck. It should be that as long as the code under test is compiled with the right flags that it should output the expected coverage data files.

Curious, if the DBus server is started on its own when compiled with the coverage flags does it produce the expected coverage data files?

[Kenneth Ekman]

Ok, thanks.
The method I'm using right now is to let the system start my server by creating a .service file naming my DBus interface and my executable. This makes the system (systemd I assume) start my server when my client app accesses the dbus interface.

If it might help to start my server in another way, I'd be happy to try it!

In my coverage report I currently only see calls done by my client side, not by the server side, despite being built with coverage flags. I tried to modify testrules.mak to hardcode target file and output (running bitbake too), but it didnt seem to help.

[Branden Archer]

This makes the system (systemd I assume) start my server when my client app accesses the dbus interface.

My understanding is that the pwd where the executable was launched from is where it will try to write the coverage stats. If systemd is launching the executable, it may be launching from somewhere it does not have write access. I think you need to control where it is launching from. I'm not familiar with flags for setting where the stats are written to. Depending on the service file I wonder if the spawned server does not have write access to the write location.

if you want to see what the server is doing you could wrap the launch of the service with strace, and write the result somewhere with open permissions, maybe in /tmp. That would show if it is trying to open a file for the stats, where, and if it fails why.

I'm not familiar with your build setup, so I can't advise on that.