1) Sure but that's the same as saying tests makes navigating the codebase harder because now when you "jump to usages" you find all the references from the tests. Probably fixable by tooling configuration.

2) For each unit test setup an independent mock of the interface for your subject-under-test. You should not create catch-all mocks for all your interfaces, unless it's to be used for offline work.

3) If you replace the process, as in the business process, you need to redo the tests as well yes. If you replace the implementation, you must throw away your "white-box" tests but should be able to keep your "black-box" tests.

1) I haven't actually seen a tooling configuration that gives you the experience of having the concrete type in your code when you write code that uses an interface (in e.g. golang or Java) for the sole purpose of swapping it out in a test.

2) Right. I agree.

3) It looks like your original post in this thread says "Do not make black box tests. Make white box tests"

1) Me neither to be honest, but would love to see it.

3) All right. That was not my intend. I think they both do different stuff, some projects need both, some only need one or the other.

What I find works well is to use dependency inversion to mock things out within your code, but mock out the transport layer.

I.e: If you have a "stack" like this:

- Application

- MainService

- ApiService

- HttpClient

What you might think of doing is replacing the ApiService with a mock, such that you can test your MainService's interactions with it.

You can do that, sure, and it's useful - but as you rightly point out now you can't find any bugs in your ApiService.

Instead, mock out the HttpClient (or if it's not Http, mock out the Socket). Typically because these kinds of things are at the bottom of the stack, they have very simple interfaces and are really easy to mock, and because the interfaces are so simple the mocks don't introduce much - if any - damage to the rest of your code around them.

There are significant advantages to doing it this way too, over using an external mocked API.

- Way faster

- More reliable

- Single codebase (if the mock API is some external NodeJS thing now you have to wrangle that too)

- You have perfect control over timing. For example, if you have a bug in your ApiService which happens when two packets get interleaved in exactly the wrong way, you can reproduce this easily. If you had a real HttpClient talking to an external process it's nigh impossible.

Good luck!

All good points, but you missed the most important part: in any mature programming language, you're not implementing the HttpClient yourself: it's a library, package, bundle, whatever. Which means that when you mock that you're not missing out on testing any code that you wrote, and the project that maintains your HttpClient (hopefully) has their own community-maintained test suite.

Have a look at VCR. It was developed for Ruby, and does exactly that: mock out the actual HTTP part of your HTTPClient.

It does this by first making the actual request and then storing that record in a plain YAML file (which you can alternatively generate yourself, by hand or from an openapi spec)

Have a look at "Ports in Other Languages" in their README to find the VCR port for your language, framework or stack.