It's interesting because Go does let you test private functions but I think it is best to avoid doing that.
The reason being is you should try to avoid testing the underlying algorithm in tests. What I mean by that is test outcomes, not the way it is done.
Why is that important?
A lot of code bases suffer when developers want to refactor, but end up having to change a load of test code so it feels like a pain.
But the very definition of refactoring should be that the behaviour of the code doesnt change! If you are testing your algorithms you are making refactoring harder.
Coming back to our example, "greetingPrefix" is just an internals of our public API. Let's pretend I did write a test, but then decided I actually preferred to not have it as a separate function (for some reason). I would have to change test code, even though I'm only refactoring.
I've waffled on a bit there, but i hope it makes sense!
It help a lot that the behaviour of the code is more importance than the way how it is done.
Usually, we reduce the internal coupling through the interface(public API), so the behavior of the interface is crucial, and the test should focus on the interface to ensure it behaves as expected. At the angle of efficiency in testing, it is not necessary to pay much attention to the internal implementation.
It's interesting because Go does let you test private functions but I think it is best to avoid doing that.
The reason being is you should try to avoid testing the underlying algorithm in tests. What I mean by that is test outcomes, not the way it is done.
Why is that important?
A lot of code bases suffer when developers want to refactor, but end up having to change a load of test code so it feels like a pain.
But the very definition of refactoring should be that the behaviour of the code doesnt change! If you are testing your algorithms you are making refactoring harder.
Coming back to our example, "greetingPrefix" is just an internals of our public API. Let's pretend I did write a test, but then decided I actually preferred to not have it as a separate function (for some reason). I would have to change test code, even though I'm only refactoring.
I've waffled on a bit there, but i hope it makes sense!
It help a lot that the behaviour of the code is more importance than the way how it is done.
Usually, we reduce the internal coupling through the interface(public API), so the behavior of the interface is crucial, and the test should focus on the interface to ensure it behaves as expected. At the angle of efficiency in testing, it is not necessary to pay much attention to the internal implementation.
I am very interested in this topic, thanks! paperminecraft.io