Testability Strategy

[bkcsoft]

Reference #2293

Basically, we need more tests 😄

Should this go in go-gitea/proposals instead?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[xinity]

👍 for go-gitea/proposals

[tboerger]

And what do you want to propose? :D

[andreynering]

I think this is a big topic, so we should break it in small parts.

Unit tests

First of all we should have more unit tests. These tests should be memory only (e.g.: they shouldn't touch the database, git, and if possible even the filesystem). They are tests for isolated parts of the codebase.

Integration testing

This is harder, here we have to simulate HTTP requests and check if the behavior is correct. I think there are two main difficulties:

How to deal with a database

• Mocking the database
• We can test against a real database

I prefer to use a real database, since mocking will not catch problems like wrong SQL sintax, constraints violations, etc. #86 is a example that uses this approach. We can use a memory database for performance.

How to deal with Git

• We can mock the interface that talk to git
• We can write scripts to generate repositories and use real Git

In this case I prefer mocking since it will be easier than the alternative.

---

After we have a consensus it should be write in a formal document.

[strk]

+1 for real database, and ideally against all the supported and available databases systems
And also I think using real git would be better

Should this go under go-gitea/proposals, btw ?

[metalmatze]

Just want to add that I like to be mostly stdlib for unit tests.
Nevertheless I find https://godoc.org/github.com/stretchr/testify/assert extremely useful to prevent a lot of boilerplate.

val, err := somefunc()
if err != nil {
    t.Error(err)
}
if val != "foobar" {
    t.Error("val is not foobar")
}

would become:

val, err := somefunc()
assert.Nil(t, err)
assert.Equals(t, "foobar", val)

That's it.

[andreynering]

@metalmatze I agree. Go Convey was the convention on Gogs, but I also prefer testify/assert. That's another thing we should decide.

[makhov]

Convey is awful.
@metalmatze, note that testify/assert has methods assert.Error and assert.NoError to test errors

[metalmatze]

@makhov Even better! 😄 👍

[lunny]

Unit Tests first, that's great idea. And let's send more unit tests PRs.
About the unit test framework, we have to determine one ASAP.

@makhov, do you have time on code review PRs? If you like, I want to invite you to maintainers team.

[makhov]

@lunny right after somebody explain me what happens :)

[lunny]

@makhov Welcome back! I have moved you from Advisor Team to Maintainers Team.

[odinuge]

Isn't pure golang testing an equally good approach to unit testing? The assertion approach works, but in my opinion, the normal go-one works better. Eg. it forces the user testing to handle errors, instead of just panicking.

Ofc. they both comes with some different pros and cons, but the most important thing (as @lynny states) is to agree on "one" way to do it, and to actually write the tests! :)

[makhov]

We use testing with testify/assert and it works for us.