2
When it comes to "best practices" to mock interfaces, there's a number of things to consider, not in the least: ease of use. Over the years, I've taken to use a mock generator tool. Rather than just implementing the interface in question, GoMock supports a lot of other useful things. You can read more about it here.
The way to use it in your case ...
2
This seems fine to me: it's nice and simple, and I've seen this pattern used "in the wild" before. One thing you could do is, in the MockUserRepo proxying functions, if the function variable is nil, either execute a default implementation, or return a more specific error (or even panic). For example:
func (m *MockUserRepo) GetUserByEmail(s string) (...
1
I think the code could benefit a struct for the database instead of global state.
You can use a New method instead of init() where you pass in the params, which would differet from test and production.
I also demonstrated that you can keep the connection open and reuse it within the struct. If you prefer a lazy approach, you can omit this and create a the ...
1
@Jeremy Hunt's great answer has covered an approach that will make your classes more testable. I'm just going to add a few other things to think about, with your existing code.
given..when..then
You're naming your tests using a given..when..then approach. If that's your preference, then you may want to consider using Mockito's BDD extensions which might ...
Only top voted, non community-wiki answers of a minimum length are eligible
