16

I know that Golang has a testing package that allows for running unit tests. This seems to work well for internally calling Golang functions for unit tests but it seems that some people were trying to adapt it for API testing as well.

Given to the great flexibility of automated testing frameworks like Node.js' Mocha with the Chai assertion library, for what kind of tests does it make sense to use Golang's testing package vs. something else?

Thanks.

Spikey
  • 435
  • 2
  • 5
  • 9

4 Answers4

5

I agree with the comment by @eduncan911. More specifically you can design your API with testing in mind by making sure that your handlers accept an

http.ResponseWriter

as a parameter in addition to the appropriate request. At that point you will be set to declare a new request:

req, err := http.NewRequest("GET", "http://example.com", nil)

as well as a new httptest recorder:

recorder := httptest.NewRecorder()

and then issue the new test request to your handler:

yourHandler(recorder, req)

so that you can finally check for errors/etc. in the recorder:

if recorder.Code != 200 {
  //do something
}
daplho
  • 1,113
  • 1
  • 11
  • 25
  • 1
    Niko - it sounds like you are saying that the Golang built-in testing package is sufficient/robust/and easy enough for all types of tests and that I have no use in looking at any other solutions? – Spikey Feb 08 '17 at 13:31
  • Yes - it has worked well for me as far as API testing is concerned. – daplho Feb 09 '17 at 14:35
  • 2
    Testing handlers is fine, but that does not test that the handlers are actually used by the final application, nor does it test that the routing works well. – Renra Feb 26 '19 at 08:29
  • 1
    While I found this answer interesting, I'd argue that testing the handler can be conveniently bypassed by structuring the API-called code in so that the handler itself is just a very tiny integration layer. The actual code will be unit tested the usual way. – Marcello Romani Mar 06 '19 at 09:40
2

For making a dummy request, you have to first initialise the router and then set the server and after that make request. Steps to be follow:

1. router := mux.NewRouter() //initialise the router
2. testServer := httptest.NewServer(router) //setup the testing server
3. request,error := http.NewRequest("METHOD","URL",Body)
4. // We create a ResponseRecorder (which satisfies http.ResponseWriter) to record the response.
        resp := httptest.NewRecorder()
5. handler := http.HandlerFunc(functionname)
// Our handlers satisfy http.Handler, so we can call their ServeHTTP method
// directly and pass in our Request and ResponseRecorder.
        handler.ServeHTTP(resp, req)
Cœur
  • 37,241
  • 25
  • 195
  • 267
Nikta Jn
  • 346
  • 3
  • 7
0

I use smartystreets goconvey and assertions packages regularly. While the stdlib offers most everything you need, one thing I think it lacks is "quality of life" features.

The goconvey package will provide you with a nice web browser interface with hot reload. Everytime you update, it re-runs. You can also selectively choose what runs. So I typically open another console with it running which pops open a browser tab, as I code. It also makes looking at code coverage easy and convenient.

Organizing and nesting your test cases is also made easy and then renders nicely in your web browser.

Then of course the assertions package just provides you with some shortcuts.

What I've found is that this saves a lot of boilerplate and time. I'd be writing all the same stuff for each project otherwise.

It also makes your tests more consistent. If you have a library of assertions and tools, you will reach for one there first before building a custom pattern that you then deviate from in another test. It's not hard to end up with messy, hard to read tests.

There's other packages that help with testing APIs and HTTP requests as well. So like others said, you can do it from scratch, or you can use a package that takes care of the boilerplate. It could leave your tests shorter and cleaner.

So "what kind of tests?" All of them pretty much in my experience. I've always benefitted from other packages. Though the important thing to keep in mind is that all this is still built on top of the already awesome testing available in Golang. One reason why I like Golang over other languages is because it has most everything baked in already. I'm not bolting on something that's missing, I'm simply enhancing it for my work flow and preferences. Then the next person who comes along to run tests for my package is actually free to use just the CLI of they want. No need to run goconvey in their browser. So the preference parts stay preferential. This is not quite so common elsewhere.

Tom
  • 3,507
  • 1
  • 29
  • 29
0

Here's how I tested my API: https://github.com/cyruzin/feelthemovies/blob/master/internal/app/controllers/controller_test.go. Digging around I found a interesting func called "func TestMain(m *testing.M) {}" that create a main routine for tests. You can use to setup your dependencies and teardown.

Cyro
  • 609
  • 5
  • 11