Seems like we might have a v2 version for gRPC middlewares!
I was going through one of the PRs of the
go-grpc-middlewares and was required to make a utility function private. It was necessary, because we use that function internally, and it does not make sense to make it public. Sounds like a fair requirement?
While I tried to make it private, I found some deeper implications. For starters, I found that, the testing package used the particular function -
JitterUp, which made it tougher to make it private.
On going through numerous stack overflow answers, I found this post quite interesting and educational for how testing would work in Golang, particularly the conventions.
White and Black Box testing
The packaging of test files can follow the convention of white/black box testing, and this made me ponder about the design decisions we might want to take for how we want to test the package.
Black Box Testing
We can use different package names(and different package) for tests and core logic. For instance,
package myfunc for core package and
package myfunc_test for the tests. This makes sure, you are calling the API Interface of your core package, so that your tests might equally import them, as any other function would do.
White Box Testing
We can use same package name
package myfunc, so that we can use all the non-exported identifiers, functions and methods. Since
JitterUp was being used internally in the tests as well, it made sense to make the test package internal.
Which one is better?
Ultimately, both of them are fine to use, as long you know what to expect. Black Box testing provides api compatibility out of the box, while white box testing makes sure that you can use internal methods and functions.