CODEWITHSUNDEEP
apirestunit-testingtestinggo
shadyyx
shadyyx

Reputation: 16065

GO Unit testing structured REST API projects

I am trying to write nice unit tests for my already created REST API. I have this simple structure:

ROOT/
    config/
    handlers/
    lib/
    models/
    router/
    main.go

config contains configuration in JSON and one simple config.go that reads and parses JSON file and fills the Config struct. handlers contains controllers (i.e. handlers of respective METHOD+URL described in router/routes.go). lib contains some DB, request responder and logger logic. models contains structs and their funcs to be mapped from-to JSON and DB. Finally router contains the router and routes definition.

Now I was searching and reading a lot about unit testing REST APIs in GO and found more or less satisfying articles about how to set up a testing server, define routes and test my requests. All fine. BUT only if you want to test a single file!

My problem is now how to set up the testing environment (server, routes, DB connection) for all handlers? With the approach found here (which I find very easy to understand and implement) I have one problem: either I have to run tests separately for each handler or I have to write test suites for all handlers in just one test file. I believe you understand that both cases are not very happy (1st because I need to preserve that running go test runs all tests that succeed and 2nd because having one test file to cover all handler funcs would become unmaintainable).

By now I have succeeded (according to the linked article) only if I put all testing and initializing code into just one func per XYZhandler_test.go file but I don't like this approach as well.

What I would like to achieve is kind of setUp() or init() that runs once with first triggered test making all required variables globally visible and initialized so that all next tests could use them already without the need of instantiating them again while making sure that this setup file is compiled only for tests...

I am not sure if this is completely clear or if some code example is required for this kind of question (other than what is already linked in the article but I will add anything that you think is required, just tell me!

Upvotes: 1

Views: 1773

Answers (2)

fl0cke
fl0cke

Reputation: 2884

Test packages, not files!

Since you're testing handlers/endpoints it would make sense to put all your _test files in either the handlers or the router package. (e.g. one file per endpoint/handler).

Also, don't use init() to setup your tests. The testing package specifies a function with the following signature:

func TestMain(m *testing.M)

The generated test will call TestMain(m) instead of running the tests directly. TestMain runs in the main goroutine and can do whatever setup and teardown is necessary around a call to m.Run. It should then call os.Exit with the result of m.Run

Inside the TestMain function you can do whatever setup you need in order to run your tests. If you have global variables, this is the place to declare and initialize them. You only need to do this once per package, so it makes sense to put the TestMain code in a seperate _test file. For example: 

package router

import (
    "testing"
    "net/http/httptest"
) 

var (
    testServer *httptest.Server
)

func TestMain(m *testing.M)  {
    // setup the test server
    router := ConfigureRouter()
    testServer = httptest.NewServer(router)

    // run tests
    os.Exit(m.Run())
}

Finally run the tests with go test my/package/router.

Upvotes: 1

WeakPointer
WeakPointer

Reputation: 3322

Perhaps you could put the setup code that you want to use from multiple unit test files into a separate package that only the unit tests use?

Or you could put the setup code into the normal package and just use it from the unit tests.

It's been asked before but the Go authors have chosen not to implicitly supply a test tag that could be used to selectively enable function compiles within the normal package files.

Upvotes: 1

Related Questions