There are a few test cases I want to run for which there is a need to start a GRPC mock server. I am using gomock library for this. To start the server, I have to pass a variable of type testing.T to this function - gomock.NewController(). Since this is a kind of initialization for all the test cases, I want to do this in TestMain. But TestMain has access to only testing.M So how do I handle this case? Create a new testing.T structure in TestMain? Will it work?
It sounds like you are looking for a BeforeEach pattern. You don't have access to a testing.T object in TestMain because this is something more of a place to do initialization before and after the test suite runs.
There are a few frameworks out there that can give you a BeforeEach cheap:
Ginkgo
Onpar
to name a few.
You could also hand roll your own:
type test struct{
ctrl *gomock.Controller
mockFoo *MockFoo
// ...
}
func beforeEach(t *testing.T) test {
ctrl := gomock.NewController(t)
return test {
ctrl:ctrl,
mockFoo: NewMockFoo(ctrl),
}
}
func TestBar(t *testing.T) {
test := beforeEach(t)
// ...
}
func TestBaz(t *testing.T) {
test := beforeEach(t)
// ...
}
Related
How can I mock something that gets called in a package init() method?
For example:
main.go
var myService MyService = myservicepkg.New()
func init(){
response := myService.get()
}
func otherMethod(){
//do something
}
maintest.go
func Test_otherMethod(){
ctrl := NewController(t)
defer ctrl.Finish()
myServiceMock = myservicepkg.NewMock(myService)
myServiceMock.EXPECT().get().return("success")
}
The problem is that init() is called before the service is replaced by the mock.
This is the issue of work with a mutable global state.
My advice is to add a flag to not run this on certain conditions or expose a private function that can recover/update this global variable in an internal test.
This reflects your design: if it is complicate to test, perhaps you should refactor.
Create an object Application with a field Service, created on the constructor/builder/factory will be easier to test.
The usage of init is very delicate. Besides register a driver into sql packages, I never use it (perhaps to handle flags).
Perhaps you can add more OO to your design
You will need to call the otherMethod() inside init(). It can't be called before init() otherwise.
I found a workaround, you can prevent the init code from being executed in your test and test the method in isolation like this:
func init(){
if len(os.Args) > 0 && strings.HasSuffix(os.Args[0], ".test") {
log.Printf("skipping jwt.init() for testing")
} else if len(os.Args) > 1 && strings.HasSuffix(os.Args[1], "-test.run") {
log.Printf("skipping jwt.init() for testing")
} else {
response := myService.get()
}
}
This will prevent the init service calls from being called.
I have a fairly large project with many integration tests sprinkled throughout different packages. I'm using build tags to separate unit, integration and e2e tests.
I need to do some setup before running my integration and e2e tests, so I put a TestMain function in a main_test.go file in the root directory. It's pretty simple:
//go:build integration || e2e
// +build integration e2e
package test
import (
...
)
func TestMain(m *testing.M) {
if err := setup(); err != nil {
os.Exit(1)
}
exitCode := m.Run()
if err := tearDown(); err != nil {
os.Exit(1)
}
os.Exit(exitCode)
}
func setup() error {
// setup stuff here...
return nil
}
func tearDown() error {
// tear down stuff here...
return nil
}
However, when I run test:
$ go test -v --tags=integration ./...
testing: warning: no tests to run
PASS
# all of my subdirectory tests now run and fail...
I really don't want to write a TestMain in each package that requires it and was hoping I could just get away with one in the root. Is there any solution that you could suggest? Thanks.
The only alternative I can think of is setting up everything outside of code and then running the integration tests. Maybe some shell script that does setup and then calls $ go test?
The go test ./... command compiles a test binary for each package in the background and runs them one by one. This is also the reason you get a cannot use -o flag with multiple packages error if you attempt to specify an output. This is the reason code in your main package doesn't effect your sub packages.
So the only way to get this to work is to put all your setup logic in sort of "setup" package and call the shared code from all of your sub-packages(still a lot of work, I know).
Trying to avoid code repetition, I used a function that makes the setup/teardown and evaluates a function as a test.
The function should look like this
func WithTestSetup(t *testing.T, testFunction func()) {
// setup code
testFunction()
// teardown code
}
I use the t *testing.T argument to report errors in setup or teardown, but it can be omitted.
Then in your tests you can make:
func TestFoo(t *testing.T) {
WithTestSetup(
t, func() {
if err := Foo(); err != nil {
t.Fatal(err)
}
},
)
}
Just call WithTestSetup if needed, looks easier for me than add a bunch of TestMains on the project.
e.g
type test struct { // few fields}
func (t *test) createresource(res1 string,res2 string)error {
//doing some task
t.createsubresource(res1)
}
func (t *test)createsubresource(res1 string)error{
//perform some task
}
I want to write test function for createresource , how can I mock t.createsubresource(res1) call. This is legacy code and I don't have permission to modify any above function.
Your mock can be done using interfaces, as for example:
main.go
package main
type TestInterface interface {
CreateResource(res1 string, res2 string) error
CreateSubresource (res1 string) error
}
func main() {
DoSomething(new(Test))
}
func DoSomething(t TestInterface) {
t.CreateResource()
}
main_test.go
package main
import "testing"
type TestMock struct {}
func (tm *TestMock) CreateResource(res1 string, res2 string) error {
return nil
}
func (tm *TestMock) CreateSubresource(res1 string) error {
return nil
}
func TestDoSomething(t *testing.T) {
err := DoSomething(new(TestMock))
//... do your assertions
}
Why does it works like that?
Calling a function that depends on a specific structure does not allow you to inject alternatives to it, that's why a solution using interface needs to be created. By having an interface, just implement a new structure that matches that interface and pass it as a dependency injection to the procedure that will be tested.
Also, check this out:
There is no easy way, by default, to just point your original structure and tell Go to make a mock from it. Maybe some 3rd party lib can do it (but I didn't saw that yet).
In go, public and private declarations are defined by the first letter as uppercase. By the lower cases declarations in your sample I've noticed that everything is private.
Usually it is not a good practice to test private methods. There are a lot of discussions about this topic, you can take a look in this one here
There are also some support libs to make assertions and mocks like for example stretchr/testify, please make a research first.
I hope that it helps you.
I'm writing some code that uses a library called Vault. In this library we have a Client. My code makes use of this Client but I want to be able to easily test the code that uses it. I use only a couple methods from the library so I ended up creating an interface:
type VaultClient interface {
Logical() *api.Logical
SetToken(v string)
NewLifetimeWatcher(i *api.LifetimeWatcherInput) (*api.LifetimeWatcher, error)
}
Now if my code is pointed at this interface everything is easily testable.. Except let's look at the Logical() method. It returns a struct here. My issue is that this Logical struct also has methods on it that allow you to Read, Write, ex:
func (c *Logical) Read(path string) (*Secret, error) {
return c.ReadWithData(path, nil)
}
and these are being used in my project as well to do something like:
{{ VaultClient defined above }}.Logical().Write("something", something)
Here is the issue. The Logical returned from the call to .Logical() has a .Write and .Read method that I can't reach to mock. I don't want all the logic within those methods to run in my tests.
Ideally I'd like to be able to do something similar to what I did above and create an interface for Logical as well. I'm relatively new to Golang, but I'm struggling with the best approach here. From what I can tell that's not possible. Embedding doesn't work like inheritance so it seems like I have to return a Logical. That leaves my code unable to be tested as simply as I would like because all the logic within a Logical's methods can't be mocked.
I'm sort of at a loss here. I have scoured Google for an answer to this but nobody ever talks about this scenario. They only go as far as I went with the initial interface for the client.
Is this a common scenario? Other libraries I've used don't return structs like Logical. Instead they typically just return a bland struct that holds data and has no methods.
package usecasevaultclient
// usecase.go
type VaultClient interface {
Logical() *api.Logical
SetToken(v string)
NewLifetimeWatcher(i *api.LifetimeWatcherInput) (*api.LifetimeWatcher, error)
}
type vaultClient struct {
repo RepoVaultClient
}
// create new injection
func NewVaultClient(repo RepoVaultClient) VaultClient {
return &vaultClient{repo}
}
func(u *vaultClient) Logical() *api.Logical {
// do your logic and call the repo of
u.repo.ReadData()
u.repo.WriteData()
}
func(u *vaultClient) SetToken(v string) {}
func(u *vaultClient) NewLifetimeWatcher(i *api.LifetimeWatcherInput) (*api.LifetimeWatcher, error)
// interfaces.go
type RepoVaultClient interface {
ReadData() error
WriteData() error
}
// repo_vaultclient_mock.go
import "github.com/stretchr/testify/mock"
type MockRepoVaultClient struct {
mock.Mock
}
func (m *MockRepoVaultClient) ReadData() error {
args := m.Called()
return args.Error(0)
}
func (m *MockRepoVaultClient) WriteData() error {
args := m.Called()
return args.Error(0)
}
// vaultClient_test.go
func TestLogicalShouldBeSuccess(t *testing.T) {
mockRepoVaultClient = &MockRepoVaultClient{}
useCase := NewVaultClient(mockRepoVaultClient)
mockRepoVaultClient.On("ReadData").Return(nil)
mockRepoVaultClient.On("WriteData").Return(nil)
// your logics gonna make this response as actual what u implemented
response := useCase.Logical()
assert.Equal(t, expected, response)
}
if you want to test the interface of Logical you need to mock the ReadData and WriteData , with testify/mock so u can defined the respond of return of those methods and you can compare it after you called the new injection of your interface
This question already has an answer here:
Is there a way to create a function using unexported type as parameter in Golang?
(1 answer)
Closed 3 months ago.
I have a package where I have unexported struct and exported New function to create it and exported function that runs on this struct (as advised for example here: Return an unexported type from a function).
If I run the function in the same place the New is called I can run the package function but I am unable to send this entity to another function.
what is the best way to achieve this behavior without the need to have all my code in one function
this for example works:
client := package.New()
client.Foo()
but this cannot work:
client := package.New()
hello(client)
func hello(client interface{}) {
client.Foo()
}
What your hello function essentially needs is something that has a Foo function. That's why go has interfaces. There's nothing wrong with returning an unexported type (in fact, it's common and often the right thing to do). What I'd do is this:
package foobar
// whatever thing that has a Foo function
type FClient interface {
Foo()
}
func Hello(client FClient) {
client.Foo() // will work
}
The reason why you'd do it like this is to be able to unit-test this code:
package foobar_test
import (
"testing"
)
type testFC struct {
callCount uint64
}
// implement interface
func (t testFC) Foo() {
testFC.callCount++
}
func TestHello(t *testing.T) {
client := testFC{}
Hello(client)
if client.callCount != 1 {
t.Fail("dependency not called")
}
}
Of course, for more complex dependencies you'd use tools like mockgen or stuff like that, but you get the idea. By definition, a UNIT test focuses on a single UNIT of code. The last thing you'd need to do to test a package unit is to instantiate a type from another package. You should be able to mock everything your code depends on. The best way to do so is interfaces.