What you want to do is test the contract between the two objects.
One set of unit tests checks the behavior of the sub-object in isolation. This set of tests is essentially a representation of various usage scenarios (with respect to the contract) that can originate from your "big" object - the client of your sub-object.
Then you'd have another set of unit tests that focuses on the "big" object, or rather, its part of the contract. There, you replace the sub-object with a mock (or a spy) that, for each test case, fakes test-specific responses/behaviors of the sub-object, and you check if the "big" object makes the right calls, handles the responses properly, etc.
You'd have to redesign to inject the sub-object as a dependency (or add a new constructor). You can then provide a helper function/constructor/factory that returns a prebuilt "big" object for the user's convenience. That makes it easy to get started with the library, but the more advanced users still have the freedom to construct the object "manually", and inject dependencies of their choosing.
You can also throw in a couple of integration tests (in the sense that you don't use a mock, but the real dependency) to make sure everything works together.