How to execute Go functions by order in Unit Test? [duplicate] - unit-testing

Question

This question already has answers here:
How to run golang tests sequentially?
(5 answers)
Closed 12 months ago.
I am new to Go and want to write a unit test for this small API:
login request.
logout request.
I expect them to be executed by order and both requests are successful.
However, when I execute the TestAPI, the last assert is always wrong and tells me the current user (abc#abc) is not logged in. I know they run in parallel (thus when handling logout request, the backend cookie hasn't stored this username yet) but I don't know how to rewrite so that the login request always happens before the logout request.
I don't want to waste your time, but I did google it for quite a while but found no solution for my case.
Many thanks for your help!
func PostJson(uri string, param map[string]string, router *gin.Engine) *httptest.ResponseRecorder {
jsonByte, _ := json.Marshal(param)
req := httptest.NewRequest("POST", uri, bytes.NewReader(jsonByte))
w := httptest.NewRecorder()
router.ServeHTTP(w, req)
return w
}
func TestAPI(t *testing.T) {
server := setUpServer()
var w *httptest.ResponseRecorder
param := make(map[string]string)
param["email"] = "abc#abc"
param["password"] = "123"
param2 := make(map[string]string)
param2["email"] = "abc#abc"
urlLogin := "/login"
w = PostJson(urlLogin, param, server)
assert.Equal(t, 200, w.Code)
assert.Equal(t, w.Body.String(), "{\"msg\":\"login success\",\"status\":\"success\"}")
urlLogout := "/logout"
w = PostJson(urlLogout, param2, server)
assert.Equal(t, 200, w.Code)
assert.Equal(t, w.Body.String(), "{\"msg\":\"logout success\",\"status\":\"success\"}")

Answer 1

Statements within a single test run sequentially
I know they run in parallel
The statements within a single test run sequentially. Those statements are all in the same top level TestAPI test function, so they run sequentially.
On Cookies
I know they run in parallel (thus when handling logout request, the backend cookie hasn't stored this username yet)
Cookies are held by the frontend, and their content can't be trusted
There is no such thing as a "backend" cookie. A cookie is a response header from the backend that the client includes in the request headers of subsequent requests.
The implication of this is that clients have full control over the content of their cookies. Generally cookies contain an unguessable random value to identify the user, which is associated with user data in backend session storage.
If you really are putting the username in the cookie, and then trusting that username, your application's security is trivial to bypass (I just set the name of whatever user I'd like to be in my cookie before making a request).
Gin should supply a secure session management system, maybe backed by something like redis. Make sure you're using it, and not really putting user names in cookies.
You the client must store the cookie and include it in subsequent requests
Your http client bears the responsibility of including cookies from prior responses in subsequent requests. You're doing nothing to include the response cookie from the login, within the request cookie from the logout. Thus the logout request is "not logged in".
What you need is a "cookie jar," a common term for a mechanism to store and include cookies for subsequent requests. One is provided by https://pkg.go.dev/net/http/cookiejar and can be added to an http.Client, but you're not actually using an http.Client - you're calling your server handler on the request directly.
Simple option: let http.Client handle request cookies for you:
Refactor your test to run a "real" http server with testhttp and then make
"real" requests against the server.
Use https://pkg.go.dev/net/http/httptest#Server to start a test http server on localhost, with the handler you provide from you router.
Create an http.Client with a jar (https://pkg.go.dev/net/http#Client.Jar)
Then simply reuse the http client to make the requests, cookies included.
https://pkg.go.dev/net/http/cookiejar#example-New has a good example of how this could be done.
More Work: store cookies in your case, with ResponseRecorder and a direct c all to the http response handler
If you want to do what http.Client could do for you, create a cookie jar at the test level.
jar, err := cookiejar.New(&cookiejar.Options{PublicSuffixList: publicsuffix.List})
if err != nil {
t.Fail(err)
}
Include the cookies from the jar in every request and return add the cookies from the response to the jar. The obvious place to do this is your PostJson code, to which the jar could be passed as an additional argument.
Before you make the request, get the jar's cookies for the url with https://pkg.go.dev/net/http#CookieJar.Cookies. Then add those cookies to the request by iterating over the list of cookies and calling req's https://pkg.go.dev/net/http#Request.AddCookie for each.
Then "make" the request as you do now.
After the response is returned, you must add the cookies to the cookie jar.
You can access response cookies via https://pkg.go.dev/net/http/httptest#ResponseRecorder.Result on your response recorder, which will return an * http.Response. You can then call https://pkg.go.dev/net/http#Response.Cookies on that response.
Add those cookies to the jar with https://pkg.go.dev/net/http#CookieJar.SetCookies.
The code might look something like:
func PostJson(uri string, param map[string]string, router *gin.Engine, jar http.CookieJar) *httptest.ResponseRecorder {
jsonByte, _ := json.Marshal(param)
req := httptest.NewRequest("POST", uri, bytes.NewReader(jsonByte))
for _, cookie := range jar.Cookies(uri) {
req.AddCookie(cookie)
}
w := httptest.NewRecorder()
router.ServeHTTP(w, req)
jar.SetCookies(uri, w.Result().Cookies())
return w
}
A final note on the value of reproducible code in questions.
If you would have made your code something I could run without significant modification, I would have spent time implementing and testing my suggested changes, and then I could give you a working example. So next time you have a good stack over flow question, take the time to invest in complete code that we can run, maybe in a Go Playground share. In addition to making it a lot easier to provide a high qualityu answer, it's also excellent practice for you!