Unit testing a function which changes private member variables

Question

I have the following class:

class foo {
    public:
        foo() : the_count(0) {}
        ~foo() = default;

        void add_one_to_count() { the_count++; };

    private:
        int the_count;
};

In this class, a public function changes a private member variable. How can I unit-test this in such a way that I can verify what the value of the_count is without making a getter function?

Why would you want to test it? From an outside perspective, nothing is changing ;-) — André, Mar 25 '20 at 19:26
Does this answer your question? [How to do unit testing on private members (and methods) of C++ classes](https://stackoverflow.com/questions/6778496/how-to-do-unit-testing-on-private-members-and-methods-of-c-classes) — Artyer, Mar 25 '20 at 19:29
There are libraries out there exploiting explicit template specializations to do private member access without changing the class. You could also change the class by adding a `friend struct detail::unit_tester;` or doing a `#define private public` before including in the tests — Artyer, Mar 25 '20 at 19:30
imho implementation details should not be tested against, ie only the public API, if you feel that you should unit test it you can encapsulate it in a class that provides public access, and in the actual class it can be private again — 463035818_is_not_an_ai, Mar 25 '20 at 19:33
from outside there is no way to tell if `the_count` changed and thats what you want to test with unit tests: the observable behavior. If you test for private members the test will make refactoring more difficult instead of making it easier — 463035818_is_not_an_ai, Mar 25 '20 at 19:37
I know, I know, I'm probably committing some crime here regarding the testing. The reason I'm doing this I have a member function that parsers a few bytes of data, and performs some action depending on what those bytes of data are. I want to check if the logic of my parser is correct. I'm beginning to think I need to seperate everything to make it more testable, this way I can add getter/setters because I need for functionality, not just for testing. — JimBob, Mar 25 '20 at 19:40
in the best case what you need for functionality and what you need for testing is exactly the same. Your example isnt the best because strictly speaking there is no functionality of `the_count` as there is no way at all to see if it changed or not, so why would you test it — 463035818_is_not_an_ai, Mar 25 '20 at 20:06
Yeah, if I had something like `set_count()` and `get_count()` it would make a lot more sense. I've adapted my implementation accordingly anyway, it's a bit of extra work but it'll help me in the long run! — JimBob, Mar 26 '20 at 17:44

score 0 · Answer 1 · answered Oct 23 '21 at 20:07

Discussion above can be resumed as :

same old question : how to test private functions / private members. Same old answer : basically, you should not have to do so. If really you need it, it probably says that private function should be de-coupled in separate testable code.

Having testable code should be part of initial design. Testable code :

is as much as possible stateless
ban void function.
avoid side effect.

Because real program often need state-full things and side effects, the appropriate way is to develop stateless - no side effect functions where the core business (algorithm , logic) is done and test it with unit test. Side effect and state-full code using unit tested logic can then be tested with integration test.

Unit testing a function which changes private member variables

1 Answers1