> 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.