It would be perfectly logical to write a separate unit test for match,
because it's quite non-trivial.
The code you showed for
match is a pretty trivial 1-liner without any tricky edge cases, or is that like a simplified example? Anyway, I'll assume it's simplified...
Question: what's the point of putting functions and constants into the
anonymous namespace, if it makes them unusable in tests?
This question is what wanted to make me jump in here since Deduplicator already showed a perfectly good way to break in and get access through
#include trickery. But the wording here makes it sounds like testing every single internal implementation detail of everything is some kind of universal end goal, when it's far from it.
The goal of even unit testing isn't always to test every little granular internal micro-unit of functionality. The same question applies to static file-scope functions in C. You can even make the question harder to answer by asking why developers use
pimpls in C++ which would require both
#include trickery to white box, trading easy testability of implementation details for improved compilation times, e.g.
From a kind of pragmatic perspective, it might sound gross but
match may not be correctly implemented with some edge cases that cause it to trip up. However, if the sole outer class,
Foo, that has access to
match cannot possibly use it in a way that encounters those edge cases, then it's rather irrelevant to the correctness of
match has these edge cases that will never be encountered unless
Foo changes, at which point the tests of
Foo will fail and we'll know immediately.
A more obsessive mindset eager to test every single internal implementation detail (perhaps a mission-critical software, e.g.) might want to break in and party, but a lot of people don't necessarily think that's the best idea, as it would create the most brittle tests imaginable. YMMV. But I just wanted to address the wording of this question which makes it sound like this kind of uber-fine-grained-internal-detail-level testability should be an end goal, when even the most rigorous unit testing mindset might relax a bit here and avoid x-raying the internals of every class.
So why do people define functions in anonymous namespaces in C++ or as file-scope static functions with internal linkage in C, hidden from the outside world? And that's mainly it: to hide them from the outside world. That has a number of effects from reducing compile times to reducing complexity (what cannot be accessed elsewhere cannot cause problems elsewhere) and so forth. Probably testability of private/internal implementation details isn't the number one thing on people's minds when they do it over, say, reducing build times and hiding unnecessary complexity from the outside world.