I have a suite of microservices:
"Someone" can make a call to the ConnectorTypeA microservice to create a connector of type A, and it is needs to be known that "Someone" is the owner of that connector.
When ConnectorTypeA is created, it needs to register itself with ConnectorRegistrar.
The obvious option is to have ConnectorTypeA make an API call to ConnectorRegistrar to let it be known that "Someone" owns ConnectorTypeA.
The dilemma that I'm facing is I am not sure how to unit test this.
When we do the unit test for ConnectorTypeA creation, it will mock a creation through a database transaction. But if the API call is making another API call to the Registrar service, the Registrar will be making a record as well, which is wrong... as the unit test shouldn't trigger a permanent record.
Can someone please help me and point me in the right direction?
You are confusing unit test with integration tests:
You want to test your ConnectorTypeA. Meaning you only care for ConnectorTypeA output given certain inputs.
If it calls ConnectorRegistrar when processing the input, in your test you will need to mock the HTTP response that ConnectorRegistrar would return for that particular test case.
In your example, you mentioned a database. That's an integration between the service and the database. If this is what you actually want to do, you would need to fire up an instance of your ConnectorRegistrar service, and make sure it has the fixture data necessary to return what your ConnectorTypeA expect for its test case
When ConnectorTypeA is created, it needs to register itself with ConnectorRegistrar
ConnectorTypeA is created, it needs to be given a means of registering itself with something else. What that something else is is of no concern of
ConnectorTypeA. In other words, it registers itself via an injected abstraction. So within your test, you provide it with some sort of mock of
ConnectorRegistrar. In the real code, a real instance of
ConnectorRegistrar is injected into it.