I find it hard to discuss such super abstract issues, so let me transform your example into a practical one:

• func1 shall be a complicated (but pure) function, calculating a value from some input.
• func2 the same.
• glue is a "stupid" function which takes one parameter (a string which encodes the input values of func1 and func2 encoded as a structured JSON document) and returns a single string (again a JSON document)

If I were to implement tests for those, it would depend mostly on which of these functions are actually called from outside.

If I knew that 99% of all users will always only call glue, then my test would call glue. The test would not even know that func1 and func2 exist.

If, instead, the two functions were to be called often directly, and glue were just a boring add-on (a further, optional, way of calling them indirectly), then I would maybe start with writing tests for func*.

In both cases, I would write additional tests for the so far missing functions only if if were very simple/quickly done; if I had nothing better to do; or if there were other particular reasons to do it (for example, even if glue were boring and irrelevant, I might add a test for it if it were the only spot in my code where I use these JSON conversions).

In summary, there are no hard and fast rules for this; some of it comes down to taste, and to circumstances. Nothing keeps you from treating all three functions as a single unit (accessed through glue) if it makes sense in your particular case.

I find it hard to discuss such super abstract issues, so let me transform your example into a practical one:

• func1 shall be a complicated (but pure) function, calculating a value from some input.
• func2 the same.
• glue is a "stupid" function which takes one parameter (a string which encodes the input values of func1 and func2 encoded as a structured JSON document) and returns a single string (again a JSON document) - in other words, a REST API.

If I were to implement tests for those, it would depend mostly on which of these functions are actually called from outside.

If I knew that 99% of all users will always only call glue, then my test would call glue. The test would not even know that func1 and func2 exist.

If, instead, the two functions were to be called often directly, and glue were just a boring add-on (a further, optional, way of calling them indirectly), then I would maybe start with writing tests for func*.

In both cases, I would write additional tests for the so far missing functions only if if were very simple/quickly done; if I had nothing better to do; or if there were other particular reasons to do it (for example, even if glue were boring and irrelevant, I might add a test for it if it were the only spot in my code where I use these JSON conversions; this would save me from later accidentally deleteing the JSON library from my code base, or detect breakages if that library introduced breaking changes).

In summary, there are no hard and fast rules for this; some of it comes down to taste, and to circumstances. Nothing keeps you from treating all three functions as a single unit (accessed through glue) if it makes sense in your particular case.