This is a minimal proof-of-concept for a unit testing framework that can be used with OpenLLDP. The first focus is to try to fully test out the various code paths that is in the get_mac() function which was recently updated in PR #122. This is currently a viability test to see how easy that can be done while requiring as few changes to the existing code as possible to support it. It is currently able to test a few paths in that function and only required a small change to lldp_util.c to implement.

https://github.com/penguin359/openlldp/tree/test-netlink

To run the test, run ./test-netlink.sh inside the top-level folder of the checkout.

As I don't want to rely on the code actually talking to the kernel's AF_NETLINK subsystem, I decided to try using socketpair(2) to create a back-to-back pair of AF_UNIX sockets for get_mac() to talk to instead. This allows the test framework to directly send and receive all the datagrams destined for the RTNETLINK subsystem. This led to the one change that I had to make. As get_mac() creates a new netlink socket for each request, I had to break out that part of the rest of the logic which I moved to get_mac2(). The only logic left in get_mac() is the call to socket(2) and then it passed the result to get_mac2(). The test framework directly calls get_mac2() passing it half of the UNIX socket pair that was created.

Another function that needs to be stubbed out is ioctl() which is used by get_mac() to turn the ifname into an interface index number. To avoid having to modify that code, I used the linker flag --wrap which changes call to ioctl() to call __wrap_ioctl() instead which I can use for the stub. As the test doesn't currently care about the index, I just let it get left at zero for the time being.

With that taken care of, I was able to generate some RTNETLINK responses and verify that get_mac2() properly parsed out the MAC address from them.

I've avoided pulling in any specific test framework for this proof-of-concept so far, but I think Unity or GoogleTest could be interesting frameworks which I've used before. The current test is just using the standard library assert() function. I'm planning on running this test to see the codes response to large (>1024 bytes) packets both before and after the merging of PR #112 as part of the complete proof-of-concept.

Let me know what you think.