You cannot call something a glue function if you don't know how it is implemented.

Trying to figure out how to test glue functions means that you already need to know its implementation (to first establish that it is a glue function), which is an approach that fails at the first gate; because you should not be writing your test based on the knowledge of the implementation. You should be writing a test based on the behavior you want to see.

Using a mathematical example, if you have a CalculatePi method, you should not be concerned with how it calculates the value of pi, only that it calculates the value of pi. There are many ways to calculate pi, and if you write a tests that e.g. confirms if CalculatePi calls the InfiniteSeriesCalculator, then you are limiting yourself to only being allowed to calculate pi using an infinite series, and not using any other method, even though it's mathematically equally valid to do so.

Don't call your method "glue", because that tells you things you shouldn't know. Let's call it glipglop(x). Tell me what this function does. Assume that I don't know about any other methods that exist, nor will I engage you in a discussion on other methods. Tell me what this method does.

Based on that explanation, you can design your test.

Internally, maybe glipglop uses some kinds of reusability. That's great from a developer's point of view, no point inventing the wheel a second time. But from the point of view of an outside consumer or tester, this is a secret. They don't know that you reused it. And they should not base their tests on it either.

You cannot call something a glue function if you don't know how it is implemented.

Trying to figure out how to test glue functions means that you already need to know its implementation (to first establish that it is a glue function), which is an approach that fails at the first gate; because you should not be writing your test based on the knowledge of the implementation. You should be writing a test based on the behavior you want to see.

Using a mathematical example, if you have a CalculatePi method, you should not be concerned with how it calculates the value of pi, only that it calculates the value of pi. There are many ways to calculate pi, and if you write a tests that e.g. confirms if CalculatePi calls the InfiniteSeriesCalculator, then you are limiting yourself to only being allowed to calculate pi using an infinite series, and not using any other method, even though it's mathematically equally valid to do so.

Don't call your method "glue", because that tells you things you shouldn't know. Let's call it glipglop(x). Tell me what this function does. Assume that I don't know about any other methods that exist, nor will I engage you in a discussion on other methods. Tell me what this method does.

Based on that explanation, you can design your test.

Internally, maybe glipglop uses some kinds of reusability. That's great from a developer's point of view, no point inventing the wheel a second time. But from the point of view of an outside consumer or tester, this is a secret. They don't know that you reused it. And they should not base their tests on it either.

Just to address the remaining elephant I've left in the room, if part of what glipglop(x) does is specifically to create a side effect in a dependency (e.g. part of its responsibility is to send a message to MyLogger), then you would indeed confirm during the test that MyLogger was called correctly.

However, in this scenario MyLogger is part of the behavior of the method, it's not just an implementation detail. That is why this is different and why in this case you can write your test to confirm that MyLogger is being called.