Testing handlers that use Gorilla/context

I'm using gorilla/context in a web app. The example in the docs looks like:

func MyHandler(w http.ResponseWriter, r *http.Request) {
    //...

    val := context.Get(r, foo.MyKey)

    //...
}

How can I unit test a handler that works like this? The only way I've managed so far is to use the context package inside my tests. I'm thinking at the moment that I could inject a context parameter into the handler but then I'm not conforming to the HandlerFunc interface.

This is a classic cross-cutting concerns example.

You are using a 3rd party to magically handle input params for your unit under test. By that very definition, you are going to have to do some extra setup to prep the context for the state you want.

When it comes to Go http handlers (which the convention is to KISS it), you shouldn't need to "reach out of context" of your func to get extra data: keep all the data you need within your single func.

Personally, I try to avoid corrupting my handlers like this. I think I've only used gorilla's context once out of the dozens of big sites I've built. And that was basically to get around a cached response, just to keep the data refesh to the end user. Of which I simply ignored in my unit tests, as it was out-of-scrope of what I was testing.

Instead, I use middle-ware wrappers to setup the basics I want in my handles and modify the handler's signature accordingly.

• caching
• logging
• authentication and authorization
• json marshaling
• context (e.g. expected User{} object loaded from DB)

...etc. I would create a middle-ware that wraps your handler when you register it with mux that uses gorilla/context to lookup your cookie or userid or something, hidrates that user object from cache, DB, redis, etc, and then calls your handler that would have a signature like:

func MyHandler(u User, p Page, w http.ResponseWriter, r *http.Request) {
    // u is the User object loaded from middle-ware

    // p is your global Page object... etc
}

That way, your unit tests inject only the items you need under test.

And you can integration test your middle-ware on a QA server with expected User and Page objects in a datastore.

The way my team does it is to add a name to the route handler and then in the tests we call that route by name.

This is how to add a route:

r.HandleFunc("/<route>", MyHandler).Methods("GET").Name("MyHandlerByName")

Then this is how to test it

r.Get("MyHandlerByName")

One way to test handles is modify the way in which they are created. for example, Creating a function that return a http.HandlerFunc, this function can have parameters. You can mock the values that you send to the function

Without parameters

 func State() http.HandlerFunc {
        return http.HandlerFunc(func(pResponse http.ResponseWriter, r *http.Request)    {
    		// your code
    	})
    }

With Parameters

   func State(pParam1,pParam2,pParam3 ...) http.HandlerFunc {
        return http.HandlerFunc(func(pResponse http.ResponseWriter, r *http.Request)    {
    		// your code using pParam1,pParam2,pParam3 
    	})
    }

The mapping will be

http.HandleFunc("/State", State())

or

http.HandleFunc("/State", State(value1,value2,value3 ....))