Skip to content
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

[WIP] Write tests for issue API #86

Closed
wants to merge 2 commits into from
Closed

[WIP] Write tests for issue API #86

wants to merge 2 commits into from

Conversation

andreynering
Copy link
Contributor

@andreynering andreynering commented Nov 5, 2016

Please don't merge yet. Opened for discussion on testing approach.

For context see #63

Edit: to run these tests:

go test -v -tags sqlite ./routers/api/v1/repo/

@xinity xinity added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Nov 5, 2016
@andreynering andreynering mentioned this pull request Nov 5, 2016
// Does not check run user when the install lock is off.
if InstallLock {
// Does not check run user when the install lock is off or is running tests
if InstallLock && AppRunMode != RUN_MODE_TEST {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change code for testing is a bad practice

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. This is a WIP, we should abstract things using interfaces. I am open for suggestions on how to do it right.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thank you. It's very important to write testable code 👍

@@ -57,6 +57,10 @@ var (
EnableTiDB bool
)

func Database() *sql.DB {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And now we can execute SQL queries from handlers?


w, r := testutil.NewTestContext("GET", "/api/v1/repos/user1/foo/issues", "", nil, "1")
testutil.ServeHTTP(w, r)
So(w.Code, ShouldEqual, http.StatusOK)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test which test nothing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it tests if /api/v1/repos/user1/foo/issues returns status 200.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, but it useless info. /api/v1/repos/user1/foo/issues may returns 200 and {"foo": "bar"} in response body. Or {"oops": "something went wrong"}. Or Fuck the json, etc…

@tboerger tboerger added this to the 1.0.0 milestone Nov 5, 2016
@tboerger
Copy link
Member

tboerger commented Nov 5, 2016

@makhov glad that you are back :)

@DblK DblK added the pr/wip This PR is not ready for review label Nov 5, 2016
@strk strk removed this from the 1.0.0 milestone Nov 6, 2016
@tboerger tboerger added this to the 1.0.0 milestone Nov 7, 2016
@@ -263,6 +269,10 @@ var (
HasRobotsTxt bool
)

func GiteaPath() string {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exported functions should have be commented 😄

@@ -0,0 +1,31 @@
# THIS FILE EXISTS TO BE USED TO UNIT TESTS
# DON'T CHANGE IT. THIS IS NOT THE FILE GOGS WILL USE IN PRODUCTION
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GOGS ? :trollface:

# THIS FILE EXISTS TO BE USED TO UNIT TESTS
# DON'T CHANGE IT. THIS IS NOT THE FILE GOGS WILL USE IN PRODUCTION

APP_NAME = Gogs: Go Git Service
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

@lunny lunny modified the milestones: 1.1.0, 1.0.0 Nov 17, 2016
@bkcsoft
Copy link
Member

bkcsoft commented Dec 25, 2016

As I'm a big promoter of unit-tests, I'd prefer if we'd start with the model-tests instead. That way we get rid of a bunch of edge-cases before going for e2e-tests (integration, like these ones). It's also extremely hard to force edge-cases from this level, and the amount of tests would blow out of proportions. Testing models is easier since we know what goes in an out, and we don't have to force edge-cases. I also suggest that we use in-memory sqlite database

@tboerger tboerger added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 25, 2016
@andreynering
Copy link
Contributor Author

So this need more discussion...

@tboerger tboerger added reviewed/invalid and removed type/proposal The new feature has not been accepted yet but needs to be discussed first. type/testing lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. pr/wip This PR is not ready for review labels Jan 16, 2017
@tboerger tboerger removed this from the 1.1.0 milestone Jan 16, 2017
lunny pushed a commit to lunny/gitea that referenced this pull request Feb 7, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
@delvh delvh added issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea and removed reviewed/invalid labels Oct 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants