How to test Go function containing log.Fatal() - testing

Say, I had the following code that prints some log messages. How would I go about testing that the correct messages have been logged? As log.Fatal calls os.Exit(1) the tests fail.
package main
import (
"log"
)
func hello() {
log.Print("Hello!")
}
func goodbye() {
log.Fatal("Goodbye!")
}
func init() {
log.SetFlags(0)
}
func main() {
hello()
goodbye()
}
Here are the hypothetical tests:
package main
import (
"bytes"
"log"
"testing"
)
func TestHello(t *testing.T) {
var buf bytes.Buffer
log.SetOutput(&buf)
hello()
wantMsg := "Hello!\n"
msg := buf.String()
if msg != wantMsg {
t.Errorf("%#v, wanted %#v", msg, wantMsg)
}
}
func TestGoodby(t *testing.T) {
var buf bytes.Buffer
log.SetOutput(&buf)
goodbye()
wantMsg := "Goodbye!\n"
msg := buf.String()
if msg != wantMsg {
t.Errorf("%#v, wanted %#v", msg, wantMsg)
}
}

This is similar to "How to test os.Exit() scenarios in Go": you need to implement your own logger, which by default redirect to log.xxx(), but gives you the opportunity, when testing, to replace a function like log.Fatalf() with your own (which does not call os.Exit(1))
I did the same for testing os.Exit() calls in exit/exit.go:
exiter = New(func(int) {})
exiter.Exit(3)
So(exiter.Status(), ShouldEqual, 3)
(here, my "exit" function is an empty one which does nothing)

While it's possible to test code that contains log.Fatal, it is not recommended. In particular you cannot test that code in a way that is supported by the -cover flag on go test.
Instead it is recommended that you change your code to return an error instead of calling log.Fatal. In a sequential function you can add an additional return value, and in a goroutine you can pass an error on a channel of type chan error (or some struct type containing a field of type error).
Once that change is made your code will be much easier to read, much easier to test, and it will be more portable (now you can use it in a server program in addition to command line tools).
If you have log.Println calls I also recommend passing a custom logger as a field on a receiver. That way you can log to the custom logger, which you can set to stderr or stdout for a server, and a noop logger for tests (so you don't get a bunch of unnecessary output in your tests). The log package supports custom loggers, so there's no need to write your own or import a third party package for this.

If you're using logrus, there's now an option to define your exit function from v1.3.0 introduced in this commit. So your test may look something like:
func Test_X(t *testing.T) {
cases := []struct{
param string
expectFatal bool
}{
{
param: "valid",
expectFatal: false,
},
{
param: "invalid",
expectFatal: true,
},
}
defer func() { log.StandardLogger().ExitFunc = nil }()
var fatal bool
log.StandardLogger().ExitFunc = func(int){ fatal = true }
for _, c := range cases {
fatal = false
X(c.param)
assert.Equal(t, c.expectFatal, fatal)
}
}

I have using the following code to test my function. In xxx.go:
var logFatalf = log.Fatalf
if err != nil {
logFatalf("failed to init launcher, err:%v", err)
}
And in xxx_test.go:
// TestFatal is used to do tests which are supposed to be fatal
func TestFatal(t *testing.T) {
origLogFatalf := logFatalf
// After this test, replace the original fatal function
defer func() { logFatalf = origLogFatalf } ()
errors := []string{}
logFatalf = func(format string, args ...interface{}) {
if len(args) > 0 {
errors = append(errors, fmt.Sprintf(format, args))
} else {
errors = append(errors, format)
}
}
if len(errors) != 1 {
t.Errorf("excepted one error, actual %v", len(errors))
}
}

I'd use the supremely handy bouk/monkey package (here along with stretchr/testify).
func TestGoodby(t *testing.T) {
wantMsg := "Goodbye!"
fakeLogFatal := func(msg ...interface{}) {
assert.Equal(t, wantMsg, msg[0])
panic("log.Fatal called")
}
patch := monkey.Patch(log.Fatal, fakeLogFatal)
defer patch.Unpatch()
assert.PanicsWithValue(t, "log.Fatal called", goodbye, "log.Fatal was not called")
}
I advise reading the caveats to using bouk/monkey before going this route.

There used to be an answer here that I referred to, looks like it got deleted. It was the only one I've seen where you could have passing tests without modifying dependencies or otherwise touching the code that should Fatal.
I agree with other answers that this is usually an inappropriate test. Usually you should rewrite the code under test to return an error, test the error is returned as expected, and Fatal at a higher level scope after observing the non-nil error.
To OP's question of testing that the that the correct messages have been logged, you would inspect inner process's cmd.Stdout.
https://play.golang.org/p/J8aiO9_NoYS
func TestFooFatals(t *testing.T) {
fmt.Println("TestFooFatals")
outer := os.Getenv("FATAL_TESTING") == ""
if outer {
fmt.Println("Outer process: Spawning inner `go test` process, looking for failure from fatal")
cmd := exec.Command(os.Args[0], "-test.run=TestFooFatals")
cmd.Env = append(os.Environ(), "FATAL_TESTING=1")
// cmd.Stdout, cmd.Stderr = os.Stdout, os.Stderr
err := cmd.Run()
fmt.Printf("Outer process: Inner process returned %v\n", err)
if e, ok := err.(*exec.ExitError); ok && !e.Success() {
// fmt.Println("Success: inner process returned 1, passing test")
return
}
t.Fatalf("Failure: inner function returned %v, want exit status 1", err)
} else {
// We're in the spawned process.
// Do something that should fatal so this test fails.
foo()
}
}
// should fatal every time
func foo() {
log.Printf("oh my goodness, i see %q\n", os.Getenv("FATAL_TESTING"))
// log.Fatal("oh my gosh")
}

I've combined answers from different sources to produce this:
import (
"bufio"
"bytes"
"errors"
"fmt"
"io/ioutil"
"log"
"os"
"os/exec"
"os/user"
"strings"
"testing"
"bou.ke/monkey"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/mock"
"github.com/stretchr/testify/require"
)
func TestCommandThatErrors(t *testing.T) {
fakeExit := func(int) {
panic("os.Exit called")
}
patch := monkey.Patch(os.Exit, fakeExit)
defer patch.Unpatch()
var buf bytes.Buffer
log.SetOutput(&buf)
for _, tc := range []struct {
cliArgs []string
expectedError string
}{
{
cliArgs: []string{"dev", "api", "--dockerless"},
expectedError: "Some services don't have dockerless variants implemented yet.",
},
} {
t.Run(strings.Join(tc.cliArgs, " "), func(t *testing.T) {
harness := createTestApp()
for _, cmd := range commands {
cmd(harness.app)
}
assert.Panics(t, func() { harness.app.run(tc.cliArgs) })
assert.Contains(t, buf.String(), tc.expectedError)
buf.Reset()
})
}
}
Works great :)

You cannot and you should not.
This "you must 'test' each and every line"-attitude is strange, especially for terminal conditions and that's what log.Fatal is for.
(Or just test it from the outside.)

Related

Mock sql query Golang

I have a function :
func (db *DBSqlx) GetRefreshToken(oldToken string, tx *sqlx.Tx) (string, error) {
var refreshToken string
err := db.TemplateGet(
tx,
&refreshToken,
`query`,
oldToken,
)
if err != nil {
return "", errors.Wrap(err, "не удалось запросить рефреш токен для указанного токена")
}
return refreshToken, err
}
How to write a test for this function with mock response?
DB has type :
type DBSqlx struct {
PgConn *sqlx.DB
PgConnCtx context.Context
}
I tried to write this code. But I don't understand how to use the package correctly.
db, mock, err := sqlmock.New()
if err != nil {
t.Fatalf("an error '%s' was not expected when opening a stub database connection", err)
}
defer db.Close()
mock.ExpectQuery("query").WillReturnRows()
You can abstract your storage and underlying db handle (for making it useful with pure db and tx) using some wrapper and then substitute it with another stub interface. It does not even need to include additional libraries to your codebase.
You should keep in mind potential serialization issues with real database, NULL values and etc, adding some intergration testing with real data using https://github.com/ory/dockertest
But for simple cases wrapper is enough
// root package
type TokenStorage interface {
GetToken(ctx context.Context, oldToken string) (string, error)
}
// yourtestfile_test.go
type TokenStorageStub struct {}
func (t *TokenStorageStub) GetToken(ctx context.Context, oldToken string) (string, error) {
b := make([]byte, 16)
n, err := rand.Read(b)
if n != len(b) || err != nil {
return "", fmt.Errorf("could not successfully read from the system CSPRNG.")
}
return hex.EncodeToString(b), nil
}
// postgres || mysql || sqlite package
// TokenStorage impelements root interface using postgres.
type TokenStorage struct {
db ExtendedDB
}
func NewTokenStorage(db ExtendedDB) (*TokenStorage, error) {
if db == nil {
return nil, errors.New("provided db handle is nil")
}
return &TokenStorage{db: db}, nil
}
func (s *TokenStorage) GetToken(ctx context.Context, oldToken string) (string, error) {
const query = `SELECT ...`
var token string
if err := s.db.QueryRowContext(ctx, query, oldToken).Scan(&token); err != nil {
if errors.Is(err, sql.ErrNoRows) {
return nil, rootpkg.ErrTokenNotFound
}
return nil, fmt.Errorf("postgres: problem while get token using old token: %w", err)
}
return token, nil
}
// Queryer is an interface used for selection queries.
type Queryer interface {
QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error)
QueryRowContext(ctx context.Context, query string, args ...interface{}) *sql.Row
}
// Execer is an interface used for executing queries.
type Execer interface {
ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error)
}
// ExtendedDB is a union interface which can query, and exec, with Context.
type ExtendedDB interface {
Queryer
Execer
}
You could use something like https://github.com/DATA-DOG/go-sqlmock to mock database queries with all kinds of control over responses by the database.
Though it should be noted, that mocking database queries in tests is generally not considered good testing practice because it is most likely testing the actual implementation of your program and not it's behavior.

How do I stub sqlmock to never return error?

I can not test the function NewDao that uses a database arbitrarily. I want to check whether the returned Dao have neither nil client nor nil product.
type Dao struct {
client ClientDao
product ProductDao
}
func (d *Dao) Client() ClientDao {
return d.client
}
func (d *Dao) Product() ProductDao {
return d.product
}
func NewDao(db *sql.DB) (*Dao, error) {
if db == nil {
return nil, errors.New("Can't create a dao from nil database")
}
client, err := newClientDao(db) // Uses db arbitrarily
if err != nil {
return nil, err
}
product, err := newProductDao(db) // Uses db arbitrarily
if err != nil {
return nil, err
}
return &Dao{client, product}, nil
}
I test NewDao() using sqlmock but it always fails because I don't know what the mock needs to expect.
func TestNewDao(t *testing.T) {
db, mock, err := sqlmock.New()
if err != nil {
t.Fatal("Can't create database for test dao")
}
// How to set mock to expect anything and never fail?
// mock.ExpectQuery(any) ?
dao, err := NewDao(db)
// err is never nil, because mock has no expectations
if err != nil {
t.Fatal("Can't create dao for test dao.User %q", err)
}
if dao.User() == nil {
t.Fatalf("User dao is nil")
}
if dao.Client() == nil {
t.Fatalf("Client dao is nil")
}
}
Does any one know how to stub the sqlmock for achieving my purpose? Or can appoint an alternative to sqlmock lib?
You are missing the second item in your last return in NewDao:
return &Dao{client, product}
should be:
return &Dao{client, product}, nil
Return statements have to "return" all the things declared in the function header.
Your Dao.Client and Dao.Product methods themselves make no calls to any dependency and because of that there is nothing for you to mock. There is no point in using a mock for testing these two methods.
And although testing one liners like these may not be the most sensible thing to do, if you want to test them anyway you just need to make sure that the value they return equals the value of the field that they're supposed to return.
func TestDaoClient(t *testing.T) {
var client ClientDao // TODO: prepare a client dao value for test
tests := []struct{
name string
dao *Dao
want ClientDao
}{{
name: "should return client dao",
dao: &Dao{client: client},
want: client,
}, {
name: "should return nil",
dao: &Dao{client: nil},
want: nil,
}}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := tt.dao.Client(); !reflect.DeepEqual(got, tt.want) {
t.Errorf("client got=%v, want=%v", got, tt.want)
}
})
}
}
Now you can do the same for the Dao.Product method.

golang unit test: inner function parameters

I have simple work flow in go functions, but when come to unit test, I'm stuck at passing parameter to inner functions, or mock inner function return results.
code:
package myFunc
import (
myPackage
bookPackage
)
func Init() (err error) {
err = getResource(myPackage.GetPath())
...
}
func getResource(path string) (err error) {
// get resource from path ...
err := bookPackage.GetBook(path)
}
test:
package myFunc
import "testing"
func TestInit(t *testing.T) {
if err := Init(); err != nil {
t.Fatal("test failed")
}
}
result:
--- FAIL: TestInit (0.00s)
Failed to read path ...
What will be the general solution to this type of scenarios? for example if getResource() calls getBooks() and its parameter comes from another source?
How to mock getBooks() return result, without actually running it?
Thanks,
I'm assuming this isn't real code, since you are calling unexported functions? myPackage.getPath() should never work.
Anyways, the way I tend to do it is to export anything that I need to change in order to test:
package myPackage
var Path string
func init() {
Path = "/path/to/default/path"
}
func GetPath() {
return Path
}
and then when you test, you can just override that variable to whatever you need it to be:
package myFunc
import (
"testing"
"myPackage"
)
func TestInit(t *testing.T) {
myPackage.Path = "/test/path"
if err := Init(); err != nil {
t.Fatal("test failed")
}
}

Go method chaining and error handling

I want to create a method chaining API in Go. In all examples I can find the chained operations seem always to succeed which I can't guarantee. I therefore try to extend these to add the error return value.
If I do it like this
package main
import "fmt"
type Chain struct {
}
func (v *Chain)funA() (*Chain, error ) {
fmt.Println("A")
return v, nil
}
func (v *Chain)funB() (*Chain, error) {
fmt.Println("B")
return v, nil
}
func (v *Chain)funC() (*Chain, error) {
fmt.Println("C")
return v, nil
}
func main() {
fmt.Println("Hello, playground")
c := Chain{}
d, err := c.funA().funB().funC() // line 24
}
The compiler tells me chain-err-test.go:24: multiple-value c.funA() in single-value context and won't compile. Is there a good way so funcA, funcB and funcC can report an error and stop that chain?
Is there a good way so funcA, funcB and funcC can report an error and stop that chain?
Unfortunately, no, there is no good solution to your problem. Workarounds are sufficiently complex (adding in error channels, etc) that the cost exceeds the gain.
Method chaining isn't an idiom in Go (at least not for methods that can possibly error). This isn't because there is anything particularly wrong with method chains, but a consequence of the idiom of returning errors instead of panicking. The other answers are workarounds, but none are idiomatic.
Can I ask, is it not idiomatic to chain methods in Go because of the consequence of returning error as we do in Go, or is it more generally a consequence of having multiple method returns?
Good question, but it's not because Go supports multiple returns. Python supports multiple returns, and Java can too via a Tuple<T1, T2> class; method chains are common in both languages. The reason these languages can get away with it is because they idiomatically communicate errors via exceptions. Exceptions stop the method chain immediately and jump to the relevant exception handler. This is the behavior the Go developers were specifically trying to avoid by choosing to return errors instead.
You can try like that:
https://play.golang.org/p/dVn_DGWt1p_H
package main
import (
"errors"
"fmt"
)
type Chain struct {
err error
}
func (v *Chain) funA() *Chain {
if v.err != nil {
return v
}
fmt.Println("A")
return v
}
func (v *Chain) funB() *Chain {
if v.err != nil {
return v
}
v.err = errors.New("error at funB")
fmt.Println("B")
return v
}
func (v *Chain) funC() *Chain {
if v.err != nil {
return v
}
fmt.Println("C")
return v
}
func main() {
c := Chain{}
d := c.funA().funB().funC()
fmt.Println(d.err)
}
If you have control over the code and the function signature is identical you can write something like:
func ChainCall(fns ...func() (*Chain, error)) (err error) {
for _, fn := range fns {
if _, err = fn(); err != nil {
break
}
}
return
}
playground
You can make your chain lazy by collecting a slice of funtions
package main
import (
"fmt"
)
type (
chainFunc func() error
funcsChain struct {
funcs []chainFunc
}
)
func Chain() funcsChain {
return funcsChain{}
}
func (chain funcsChain) Say(s string) funcsChain {
f := func() error {
fmt.Println(s)
return nil
}
return funcsChain{append(chain.funcs, f)}
}
func (chain funcsChain) TryToSay(s string) funcsChain {
f := func() error {
return fmt.Errorf("don't speek golish")
}
return funcsChain{append(chain.funcs, f)}
}
func (chain funcsChain) Execute() (i int, err error) {
for i, f := range chain.funcs {
if err := f(); err != nil {
return i, err
}
}
return -1, nil
}
func main() {
i, err := Chain().
Say("Hello, playground").
TryToSay("go cannot into chains").
Execute()
fmt.Printf("i: %d, err: %s", i, err)
}
You don't actually need channels and/or contexts to get something like this to work. I think this implementation meets all your requirements but needless to say, this leaves a sour taste. Go is not a functional language and it's best not to treat it as such.
package main
import (
"errors"
"fmt"
"strconv"
)
type Res[T any] struct {
Val T
Halt bool
Err error
}
// executes arguments until a halting signal is detected
func (r *Res[T]) Chain(args ...func() *Res[T]) *Res[T] {
temp := r
for _, f := range args {
if temp = f(); temp.Halt {
break
}
}
return temp
}
// example function, converts any type -> string -> int -> string
func (r *Res[T]) funA() *Res[string] {
s := fmt.Sprint(r.Val)
i, err := strconv.Atoi(s)
if err != nil {
r.Err = fmt.Errorf("wrapping error: %w", err)
}
fmt.Println("the function down the pipe is forced to work with Res[string]")
return &Res[string]{Val: strconv.Itoa(i), Err: r.Err}
}
func (r *Res[T]) funB() *Res[T] {
prev := errors.Unwrap(r.Err)
fmt.Printf("unwrapped error: %v\n", prev)
// signal a halt if something is wrong
if prev != nil {
r.Halt = true
}
return r
}
func (r *Res[T]) funC() *Res[T] {
fmt.Println("this one never gets executed...")
return r
}
func (r *Res[T]) funD() *Res[T] {
fmt.Println("...but this one does")
return r
}
func funE() *Res[string] {
fmt.Println("Chain can even take non-methods, but beware of nil returns")
return nil
}
func main() {
r := Res[string]{}
r.Chain(r.funA, r.funB, r.funC).funD().Chain(funE).funC() // ... and so on
}
How about this approach: Create a struct that delegates Chain and error, and return it instead of two values. e.g.:
package main
import "fmt"
type Chain struct {
}
type ChainAndError struct {
*Chain
error
}
func (v *Chain)funA() ChainAndError {
fmt.Println("A")
return ChainAndError{v, nil}
}
func (v *Chain)funB() ChainAndError {
fmt.Println("B")
return ChainAndError{v, nil}
}
func (v *Chain)funC() ChainAndError {
fmt.Println("C")
return ChainAndError{v, nil}
}
func main() {
fmt.Println("Hello, playground")
c := Chain{}
result := c.funA().funB().funC() // line 24
fmt.Println(result.error)
}

How to test os.exit scenarios in Go

Given this code
func doomed() {
os.Exit(1)
}
How do I properly test that calling this function will result in an exit using go test? This needs to occur within a suite of tests, in other words the os.Exit() call cannot impact the other tests and should be trapped.
There's a presentation by Andrew Gerrand (one of the core members of the Go team) where he shows how to do it.
Given a function (in main.go)
package main
import (
"fmt"
"os"
)
func Crasher() {
fmt.Println("Going down in flames!")
os.Exit(1)
}
here's how you would test it (through main_test.go):
package main
import (
"os"
"os/exec"
"testing"
)
func TestCrasher(t *testing.T) {
if os.Getenv("BE_CRASHER") == "1" {
Crasher()
return
}
cmd := exec.Command(os.Args[0], "-test.run=TestCrasher")
cmd.Env = append(os.Environ(), "BE_CRASHER=1")
err := cmd.Run()
if e, ok := err.(*exec.ExitError); ok && !e.Success() {
return
}
t.Fatalf("process ran with err %v, want exit status 1", err)
}
What the code does is invoke go test again in a separate process through exec.Command, limiting execution to the TestCrasher test (via the -test.run=TestCrasher switch). It also passes in a flag via an environment variable (BE_CRASHER=1) which the second invocation checks for and, if set, calls the system-under-test, returning immediately afterwards to prevent running into an infinite loop. Thus, we are being dropped back into our original call site and may now validate the actual exit code.
Source: Slide 23 of Andrew's presentation. The second slide contains a link to the presentation's video as well.
He talks about subprocess tests at 47:09
I do this by using bouk/monkey:
func TestDoomed(t *testing.T) {
fakeExit := func(int) {
panic("os.Exit called")
}
patch := monkey.Patch(os.Exit, fakeExit)
defer patch.Unpatch()
assert.PanicsWithValue(t, "os.Exit called", doomed, "os.Exit was not called")
}
monkey is super-powerful when it comes to this sort of work, and for fault injection and other difficult tasks. It does come with some caveats.
I don't think you can test the actual os.Exit without simulating testing from the outside (using exec.Command) process.
That said, you might be able to accomplish your goal by creating an interface or function type and then use a noop implementation in your tests:
Go Playground
package main
import "os"
import "fmt"
type exiter func (code int)
func main() {
doExit(func(code int){})
fmt.Println("got here")
doExit(func(code int){ os.Exit(code)})
}
func doExit(exit exiter) {
exit(1)
}
You can't, you would have to use exec.Command and test the returned value.
Code for testing:
package main
import "os"
var my_private_exit_function func(code int) = os.Exit
func main() {
MyAbstractFunctionAndExit(1)
}
func MyAbstractFunctionAndExit(exit int) {
my_private_exit_function(exit)
}
Testing code:
package main
import (
"os"
"testing"
)
func TestMyAbstractFunctionAndExit(t *testing.T) {
var ok bool = false // The default value can be omitted :)
// Prepare testing
my_private_exit_function = func(c int) {
ok = true
}
// Run function
MyAbstractFunctionAndExit(1)
// Check
if ok == false {
t.Errorf("Error in AbstractFunction()")
}
// Restore if need
my_private_exit_function = os.Exit
}
To test the os.Exit like scenarios we can use the https://github.com/undefinedlabs/go-mpatch along with the below code. This ensures that your code remains clean as well as readable and maintainable.
type PatchedOSExit struct {
Called bool
CalledWith int
patchFunc *mpatch.Patch
}
func PatchOSExit(t *testing.T, mockOSExitImpl func(int)) *PatchedOSExit {
patchedExit := &PatchedOSExit{Called: false}
patchFunc, err := mpatch.PatchMethod(os.Exit, func(code int) {
patchedExit.Called = true
patchedExit.CalledWith = code
mockOSExitImpl(code)
})
if err != nil {
t.Errorf("Failed to patch os.Exit due to an error: %v", err)
return nil
}
patchedExit.patchFunc = patchFunc
return patchedExit
}
func (p *PatchedOSExit) Unpatch() {
_ = p.patchFunc.Unpatch()
}
You can consume the above code as follows:
func NewSampleApplication() {
os.Exit(101)
}
func Test_NewSampleApplication_OSExit(t *testing.T) {
// Prepare mock setup
fakeExit := func(int) {}
p := PatchOSExit(t, fakeExit)
defer p.Unpatch()
// Call the application code
NewSampleApplication()
// Assert that os.Exit gets called
if p.Called == false {
t.Errorf("Expected os.Exit to be called but it was not called")
return
}
// Also, Assert that os.Exit gets called with the correct code
expectedCalledWith := 101
if p.CalledWith != expectedCalledWith {
t.Errorf("Expected os.Exit to be called with %d but it was called with %d", expectedCalledWith, p.CalledWith)
return
}
}
I've also added a link to Playground: https://go.dev/play/p/FA0dcwVDOm7