I have a package that provides an object with quite a lot of features owned by it.
Let us say the object is an
HTTPServer, and when the user initializes it by providing config and a request handler object, the server would be serving HTTP with added request observabilty, panic handling, and other in-house logics.
Now, if I want to test whether a handler's panic is properly handled, I would need to start the HTTP server, send a dummy request, and set up the observability; all which is unrelated to the panic handling logic. So, besides unit testing a feature of the object being cumbersome, there would also be a lot of reason why a test might fail (which if I understand correctly, is not a good property of a unit test),
Seeing other threads, a common idea would be to separate a particular subfeature to another (private) object, then unit test that object instead.
However, the sub-object would still be owned by the
HTTPServer object, and its implementation initialized by
HTTPServer during its initialization. To
HTTPServer, the sub-object would just be an implementation detail hidden away from the user, and the unit-test of the sub-object does not guarantee that the
HTTPServer is initialized and calls the sub-object properly. So, it cannot be mocked and we still need to retest the same functionality?
So, how do you decompose a big object for testing, and how do you use the decomposed objects in the big object's unit test if the whole functionality is still owned by the big object?