* Sleep for one millisecond in the handler because the `Latency` will return `0s` sometimes and the test will fail
* The `TCPListener.File` is not supported by windows, it is unimplemented now
* Remove the `LF` in the `testdata/template/raw.tmpl`, because if set the git config `core.autocrlf=true`, will append `CR` to the raw.tmpl automatically, then test is failed on Windows
* Update gin_integration_test.go
TestUnixSocket fails if you run it twice in a row. This is due to the unix socket file persisting. Added defer to clean up.
Whats unclear is the following test TestBadUnixSocket I suspect is just looking for cruft maybe from a prior test or defaults not working, I have not enough background to say.
* Update gin_integration_test.go
I believe there is some tab issue here, tried to manual overwrite it now.
* Update gin_integration_test.go
squash you dang spaces!!!
Digging into the test code base I've found out that some of the tests for `LoadHTML*` methods are not reliable and efficient. They use timeouts to be sure that goroutine with the server has started. And even more, in old implementation, the server started only once – all the new instances silently failed due to the occupied network port.
Here is a short overview of the proposed changes:
- it's not necessary to rely on timeouts, the server starts listening synchronously and returns control when it is ready
- once the server is run, it's stopped after a test passes
- dry out http server setup
- magic with empty closure return is eliminated
- preserve router.RunTLS coverage with integration tests
As per #1230 there is an issue when using HandleContext where the context of the request is returned to the context sync.Pool before the parent request has finished, causing context to be used in a non-thread safe manner.
I've removed the bug by not entering the context back in the pool and leaving that to ServeHTTP.
There was no test coverage for this function so I've also added the test to cover it. As the bug only happens when there are concurrent requests, the tests issues hundreds of concurrent requests. Without the bug fixed the tests do consistently recreate the error.
Stephano George