> Then how do you unit test your controllers in a web app? or anything that depends on a database connection without decoupling service and repository?

From the post you responded to:

> you should be writing the concrete implementations first, then defining interfaces in the client code.

When you need to take an argument that you can swap out for another type, that's when you define your interface. Not earlier.

> Unit testing doesn't become irrelevant because you are using Go.

Unit testing doesn't become irrelevant because you don't architecture astronaut from the start. When you need to test, define an interface. But only the interface that you need when you need it.

> Just because Go is relatively new it doesn't mean software engineering best practices don't apply anymore.

By providing the client the ability to define the interface it removes the need to pretend you can plan for all circumstances upfront.

Instead, at the moment you need to be able to mock things, you make an interface and mock them.

That's not to say that you should never provide interfaces in a library, just that it's no longer the only option available.

I'm not sure why you think that unit testing becomes harder with this approach, because to me it seems far easier.

> That's not how you do test driven development via unit testing

Unit tests test concrete implementation "units", so this is completely compatible with writing unit tests.

The distinction is that you don't first declare a few all-encompassing interfaces and then their concrete implementations, but piecemeal interfaces for each API that takes those implementations - only the bits of the interface that the API in question needs.

That makes it actually even easier to do unit testing, because for a narrow test you don't need to implement irrelevant methods.