4 ms·
> Assuming the saveUserInDB function is just making a SQL query, it probably doesn’t need a unit test at all It's possible I don't know Go well enough. func (
by Supermancho 6y ago
> Assuming the saveUserInDB function is just making a SQL query, it probably doesn’t need a unit test at all
It's possible I don't know Go well enough.
func (mdb *mockDB) Exec(query string, args ...interface{}) (sql.Result, error) {
return nil, nil
}
You're specifically returning nils, which is different than the native implementation from https://golang.org/pkg/database/sql/#DB.Exec https://golang.org/pkg/database/sql/#DB.Exec
I would write a test using a mock and asserting the fact that it neither deals with an error nor does it return anything useful (no Result).
- cratermoon 6y agoThis function takes a `query` of type `string` and a variable-length list of `args` of type `interface{}`, which is anything, (real implementations would have code to determine if the type is correct), and returns `(sql.Result, error)` In this mock version, he's returning a nil for both. I take this as example code, because if the results are actually checked in the test, then the first result would have to be non-nil if the error was nil. It doesn't really matter, because the author is saying not to do this.