When I do ut of golang, I sometimes need to test the result in goroutine, I was using time.Sleep to test, I am wondering is there any better way to test.
let's say I have an example code like this
func Hello() {
go func() {
// do something and store the result for example in db
}()
// do something
}
Then when I test the func, I want to test both result in goroutine,
I am doing this:
func TestHello(t *testing.T) {
Hello()
time.Sleep(time.Second) // sleep for a while so that goroutine can finish
// test the result of goroutine
}
is there any better way to test this?
Basically, in real logic, I don't care the result in goroutine, I don't need to wait for it finished. but in test, I want to check after it finished.
Most questions of "How do I test X?" tend to boil down to X being too big.
In your case, the simplest solution is not to use goroutines in tests. Test each function in isolation. Change your code to:
func Hello() {
go updateDatabase()
doSomething()
}
func updateDatabase() {
// do something and store the result for example in db
}
func doSomething() {
// do something
}
Then write separate tests for updateDatabase and doSomething.
If you really want to check the result of a goroutine, you should use a channel like so:
package main
import (
"fmt"
)
func main() {
// in test
c := Hello()
if <-c != "done" {
fmt.Println("assert error")
}
// not want to check result
Hello()
}
func Hello() <-chan string {
c := make(chan string)
go func() {
fmt.Println("do something")
c <- "done"
}()
return c
}
https://play.golang.org/p/zUpNXg61Wn
Related
So I have some asynchronous operations happening, I can create some lambada, call a function and pass that value to them. But what i want is not to have the result of the operation as a parameter, I want to return them.
As a example, I have a class A with some listeners, if there is a result all listeners are notified. So basically the asyncFunction should return a result if there is one otherwise be suspended.
object A {
val listeners = mutableListOf<(Int) -> Unit>()
fun onResult(value: Int) {
listeners.forEach { it(value) }
}
}
fun asyncFunction(): Deferred<Int> {
return async {
A.listeners.add({ result ->
})
return result
}
}
What I'm thinking right now (maybe I'm completely on the wrong track), is to have something like a Deferred, to which i can send the result and it returns. Is there something like that? Can I implement a Deffered myself?
class A {
private val awaiter: ??? // can this be a Deferred ?
fun onResult(result: Int) {
awaiter.putResult(result)
}
fun awaitResult(): Int {
return awaiter.await()
}
}
val a = A()
launch {
val result = a.awaitResult()
}
launch {
a.onResult(42)
}
So I do know that with callbacks this can be handled but it would be cleaner and easier to have it that way.
I hope there is a nice and clean solution im just missing.
Your asyncFunction should in fact be a suspendable function:
suspend fun suspendFunction(): Int =
suspendCoroutine { cont -> A.listeners.add { cont.resume(it) } }
Note that it returns the Int result and suspends until it's available.
However, this is just a fix for your immediate problem. It will still malfunction in many ways:
the listener's purpose is served as soon as it gets the first result, but it stays in the listener list forever, resulting in a memory leak
if the result arrived before you called suspendFunction, it will miss it and hang.
You can keep improving it manually (it's a good way to learn) or switch to a solid solution provided by the standard library. The library solution is CompletableDeferred:
object A {
val result = CompletableDeferred<Int>()
fun provideResult(r: Int) {
result.complete(r)
}
}
suspend fun suspendFunction(): Int = A.result.await()
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")
}
}
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.)
I have a simple method, which just checks if a parameter is empty and then calls one of 2 methods based on a struct field.
How would I test it?
func (cT *customType) someMethod(message string) {
if message == ""{
return
}
if cT.value == nil {
cT.doFunctionOne()
} else {
cT.doFunctionTwo()
}
}
In Javascript, I would create a spy on doFunctionOne() and mock up the object.
Mocking up works well in Go as well, but how would I do the 'spying' part?
Or is there another idiomatic way to test this kind of method?
First: You wouldn't name a method "doFunctionOne" but "methodOne" :-)
If neither doFunctionOne nor doFunctionTwo has any observable effect, then there is absolutely no point in testing it. So we may assume that they do have observable side effect, either on the environment or on the customType they have been invoked on.
Now just test these side effects. This is trivial if both methods do return. If they spin up an endless loop it becomes harder, but still doable.
IMHO there is no need to "test" this method in the sense of "test whether it calls One or Two depending on value": For me this is to lowlevel, too much increasing coverage count for nothing. If you call some method it has to do something (observable effect) and you should check this effect, not the inner workings.
The idiomatic way of mocking an object in Go is to make it explicit. A healthy interface should be testable by itself. So if we have something like this:
type customType struct {
value int
}
func (c customType) doFunctionOne() {
fmt.Println("Method #1")
}
func (c customType) doFunctionTwo() {
fmt.Println("Method #2")
}
func (c customType) someMethod() {
if c.value <= 0 {
c.doFunctionOne()
} else {
c.doFunctionTwo()
}
}
We have to provide a way to change the implementation of doFunctionOne and doFunctionTwo explicitly. We can generalize the someMethod behavior using interfaces:
type customType struct {
myValue int
}
func (c customType) doFunctionOne() {
fmt.Println("Method #1")
}
func (c customType) doFunctionTwo() {
fmt.Println("Method #2")
}
func (c customType) value() int {
return c.myValue
}
type Interface interface {
value() int
doFunctionOne()
doFunctionTwo()
}
func someMethod(i Interface) {
if i.value() <= 0 {
i.doFunctionOne()
} else {
i.doFunctionTwo()
}
}
type customTestingType struct {
t *testing.T
}
func (c customTestingType) doFunctionOne() {
c.t.Log("Working")
}
func (c customTestingType) doFunctionTwo() {
c.t.Error("Not working")
}
func (c customTestingType) value() int {
return 0
}
func TestInterface(t *testing.T) {
someMethod(customTestingType{t})
}
Surely there will be more ways to provide this behavior but it depends on the particular declaration of your type. As an example, you can look at httptest package. That said, if you really want to mock your type in that way (nonidiomatic), you can some unsafe monkey patching:
package main
import (
"fmt"
"reflect"
"github.com/bouk/monkey"
)
type customType struct {
myValue int
}
func (c customType) doFunctionOne() {
fmt.Println("Method #1")
}
func (c customType) doFunctionTwo() {
fmt.Println("Method #2")
}
func (c customType) someMethod() {
if c.myValue <= 0 {
c.doFunctionOne()
} else {
c.doFunctionTwo()
}
}
func main() {
c := customType{0}
monkey.PatchInstanceMethod(reflect.TypeOf(c), "doFunctionOne",
func(c customType) {
fmt.Println("Method #1, but patched")
})
monkey.PatchInstanceMethod(reflect.TypeOf(c), "doFunctionTwo",
func(c customType) {
fmt.Println("Method #2, but patched")
})
c.someMethod()
}
You can add log before each function call.
Inject your own logger implementation, []string for example.
Check the string slice for a matching strings.
But, if you are creating a function factory it would be better if you return the function to the caller and the caller will run the function.
Then testing is straightforward.
Second but, there is only two kind of functions, flow function and logic functions.
You mixed flow and logic in the same function.
Testing difficulty is just one symptom of this bad practice.
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