I think there's other ways to test this that would be just as effective or more, without needing to expand the API of the package.

It seems to me that it is the easiest. Create a http.Request, add the vars to mux.SetVars and then forward it into the handler. There is actually no other mux code involved.
I am up for suggestions.
(thanks for the awesome package btw, using it for what seems ages)

The way I usually test is create a mock server using the net/http/httptest package and actual create a router instance. Then I send requests to the server which will call the appropriate handler and produce the vars I want to test. That way the routing can be tested as well.

Yes, I always did that too, but I noticed that testing controller handlers could be much simpler and resource friendly by simply calling them directly with a self-made http.Request instance. That way there are no unneeded server and router instances. Also then there is no need for knowing the URI. Do not get me wrong, I still test the routers. However, the dependencies of the controllers and handlers in the project are completely mockable and therefore can run perfectly fine in parallel tests. Instantiating a server and a route for every handler is just inefficient and that is the reason why I made the change in the first place.
EDIT: Also, knowing the URI is another reason to move away from the server+router test.

+1 for this change too!

@elithrar any thoughts on this?

It does add to the API a bit, but then again it doesn't add more methods to Route or Router...

My only qualm is that people may abuse it for things other than testing and that may complicate some uses of the package later...

I'd prefer to keep it private—since writing your own test helper should be a fairly simple case of calling context.Set. If you had to write a ton of boiler-plate then the argument for making it public would definitely be stronger.

Ah right, I didn't even think of that :) Right then, going to close this.

I thought so too but that does not work. The call would mimic context.Set(r, varsKey, val) and varsKey is of type contextKey. Both are not exported, so I thought I could just use the value, which is always "0". However, the key is of type interface{}, so the type of the key value becomes important. To get context.Get to work, you need a mux.contextKey(0).

Aware that this has been closed and is an older issue, but I think @zimmski makes a pretty good point that you can't use context.Set because of the private contextKey type as well. If I am testing the handlers using httptest.NewRecorder it would be great to have one of these exported.

I gave some thoughts about this too and I join @zimmski and @cam-stitt. My handlers are wrapped into several middlewares and using the mux/server approach would require me to write more code. As an example, my authentication middleware requires some specific HTTP headers which I could get rid of by calling the handler directly.

It's really unfortunate that there's no way to directly call the handler. I will be glad to provide a PR to open SetVar().