0

I have a large function, like the following:

void processMsg(uint8_t *msg) {
    //Some structure initialisation, msg parsing and the like

    for (int i=0;i<msgRegisters;++i) {
        //Process each message register
    }
}

and I have refactored the code, extracting a method, into the following:

static void processMsgRegister(uint8_t *msg, int i)
{
    //Process one register
}

void processMsg(uint8_t *msg) {
    //Some structure initialisation, msg parsing and the like

    for (int i=0;i<msgRegisters;++i) {
        processMsgRegister(msg, i);
    }
}

Now, I want to unit test this functions.

I can easily test processMsg since it is publicly available from the .h, and I have done the necessary tests for checking that the structure initialisation and parsing is correct.

The problem comes with testing the processMsgRegister internal function. I want to test it alone, without having to test each time all the processMsg external function, since I have to clutter the tests with all the msg processing callbacks, expectations and so, for no point, since it is already tested by itself.

After some comments, I think the best approach would be to move this methods to a new class, making them public there, but not publishing the class, so it can be tested independently from the rest.

So my question now is:

  • How can I implement this approach in plain C?

This question is both, from a point of view of code organisation (spliting into multiple files, and so) and from a point of view of useful compiler/linker flags for this matter.

My setup: gcc, cmake, unity, cmock

LoPiTaL
  • 2,495
  • 16
  • 23
  • This is a matter of debate and there is no clear-cut answer. See here for example: https://enterprisecraftsmanship.com/2017/10/23/unit-testing-private-methods/ In general, I would prefer _not_ testing the internals, but if they grow too complex you may have to start making exceptions or think about re-architecting your code... – mnistic Dec 13 '18 at 13:21
  • The questions asked here are really best addressed by the processes (conventions) agreed to by your organization regarding unit testing. This very general discussion on _[unit testing](https://www.blinkingcaret.com/2016/04/27/what-exactly-is-a-unit-in-unit-testing/)_ may provide some thoughts. whether or not a component of your code is public or private does not change the importance of fully testing it. A high percentage of the complexity in most APIs is contained in code modules (or functions) that are private, only the exported functions are made available. – ryyker Dec 13 '18 at 13:24
  • @ministic Ok, I understand that my first question is more a debate than a closed question. I have removed that question and left the second one, how to do it, since I agree with both of you that the internals, once are not trivial, should be tested, despite not being publicly available. – LoPiTaL Dec 13 '18 at 13:36
  • @ryyker Ok, I agre with you. I have edited the original questions, leaving only the `how?` question. – LoPiTaL Dec 13 '18 at 13:37
  • Your question is discussed here: _[Unit testing - How do I test a private function or a class that has private methods, fields or inner classes?](https://stackoverflow.com/questions/34571/how-do-i-test-a-private-function-or-a-class-that-has-private-methods-fields-or)_. This question is really language agnostic, so the principals discussed in the link should apply equally to your `C` tag. – ryyker Dec 13 '18 at 13:56
  • @ryyker Yes, but that discussion is too focused in Java, while I am interested in how to do it in `plain C`. Most of them, as the link pointed by mnistic, sugest to create a new class which publishes them, but keeping the class private. I think that approach is interesting. So now my question is more technical: how to do this in `plain C` and with `cmock`? Spliting into several `.c`? – LoPiTaL Dec 13 '18 at 14:08
  • 1
    [How to test a static function?](https://stackoverflow.com/questions/593414/how-to-test-a-static-function) shows at least one effective way to test a static function. – Jonathan Leffler Dec 13 '18 at 15:31
  • Many arguments against testing private functions are about the fact that the private interfaces are less stable. However, I don't see why making exactly the same interfaces public should make them more stable. In other words, moving the methods to a class making them public improves the accessibility of the functions from the test, for sure, but not the stability of the interfaces used. The accessibility problem, however, can also be solved using the trick from the link shared by @JonathanLeffler. – Dirk Herrmann Feb 03 '19 at 16:30

0 Answers0