-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Add integration test for signup #1135
Conversation
build fails |
@appleboy Fixed now. |
LGTM |
// Use of this source code is governed by a MIT-style | ||
// license that can be found in the LICENSE file. | ||
|
||
package integration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should move this file to routers/user/
folder and rename to auth_test.go
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The motivation that led me to this way is that it depends on /install
and some housekeeping works (creating tempdir, launching the program ... etc.). Imaging that we are testing 'merging a pull-request', We have to
- Set up a Gitea server from
/install
- Signup a user
- Create a repo
- Push a prepared repo to Gitea
- Signup another user
- Fork the repo on Gitea
- Clone it
- Make some changes to the cloned code, commit them and push them back
- Create a pull request
- Push the 'merge' button
That's what I had to do manually to test it reliably without depending on certain kept states.
Otherwise, I'd also go for the idiomatic unit test scheme.
Edit: Another approach is to prepare set-up Gitea environments and just relying on them. That could be a good idea as well. I will think about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can have an hibrid approach: we'd have an "integration" package that would have the setup and cleanup logic, but the tests itself would be on the router packages.
There's one more thing I'd change: Go routers like Macaron have an ServeHTTP
method, which can be used to simulate HTTP requests created in tests. So no need to run Gitea in a port and do a real request through the network.
These are ideas, we're totally open to discussion. =)
I will give this LGTM even there are some improvements. but this is a good beginning. |
LGTM |
Add integration test for signup.
For #63