-
Notifications
You must be signed in to change notification settings - Fork 7.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_helpers.go should be named helpers_test.go #580
Comments
Rename to conform with test files naming (closes #580)
There's a need to name it as test_helpers.go not helpers_test.go. Unit test on a package using gin will need to create test context. By renaming it to helpers_test.go CreateTestContext() becomes private. Since CreateTestContext() refers to private methods, package user now can't create his own test context. |
@roylou i didn't know that, there is any resource I can check?
Even when the first letter of the function name is capital? |
@javierprovecho unfortunately I couldn't find any web resource. This is by self exploration. If you run "go test" of the following foo_test.go: package foo
import (
"fmt"
"github.com/gin-gonic/gin"
)
func TestCreateContext() {
c, w, r := gin.CreateTestContext()
fmt.Println(c, w, r)
} It'll complain |
Maybe move this to "github.com/gin-gonic/gin/test" package then? This way people will be able to use it in testing but it won't show up by application code using gin? |
This unfortunately won't work. CreateTestContext() invokes some of gin's private function. Putting it out of github.com/gin-gonic/gin will block private function accessibility. I think exposing |
I disagree. I think we should find a cleaner API and make it work. |
The merge of #581 has broken a my tests because they relied on CreateTestContext(). Is there a workaround? |
This reverts commit 2fd607b. CreateTestContext() should work again
Seems there's trade off between API cleanness and testibility. Please let me know if there's better way to maintain testibility. Without CreateTestContext(), I'll need to really start a fake http server instead of testing against my gin router function. |
I too am missing the existence of this function. The fact that gin handlers only need to take a Context is part of what attracted me to it. The lack of an easy way to create a context for testing purposes seems like a regression to me. |
I am guessing from the lack of interest in this issue, that application code that uses gin remains untestable? |
IMO we should revert to the old state where |
That would be good for me - thanks. |
Created #688 |
You can use gin's func getGinRouter() *gin.Engine {
r := gin.Default()
r.Post("/", func (c *gin.Context) { c.String(200, "Hello") })
return r
}
func newTestContext(method, path string) (w *httptest.ResponseRecorder, r *http.Request) {
w = httptest.NewRecorder()
r, _ = http.NewRequest(method, path, nil)
r.PostForm = url.Values{}
return
}
func TestIndex(t *testing.T) {
w, r := newTestContext("POST", "/")
r.PostForm.Add("a_param", "a_value")
getGinRouter().ServeHTTP(w, r)
assert.Equal(t, 200, w.Code)
assert.Equal(t, "Hello", w.Body.String())
} I only miss the ability to access gin's context inside my tests. Otherwise, it works very well. A section about how to write tests with Gin would be important for new users. |
Why not make
When testing, create a new
This means |
Please consider the PR #707 |
any update on it? need this exported func CreateTestContext |
I also need CreateTestContext to test my handler independent of the http router/application. Any updates? |
Hi all, already fixed by #707 |
test_helpers.go
is built with the package. It should be built only when testing which means it should have the suffix_test.go
. One side effect is that is that bytest_helpers.go
usinghttptest
every program that usesgin
gets-httptest.serve
flag.Now run the program with
--help
and you'll see:The text was updated successfully, but these errors were encountered: