I'd like to hear about your approach to testing

[ivis-kuwata]

Hello. I'm a Japanese developer from IVIS Inc. and I'd like to hear about your approach to testing.

We are forking your code and developing it to contribute to open science in Japan.
I'm wondering why there are no unit tests defined for functions that take *context.Context struct as an argument, in the internal/route/repo directory etc..

My apologies if I have missed any documentation on this topic. However, if it is possible, I would like to know what the discussion was among the original "gogs" development team regarding this part of the test.
Personally, I find it kind of odd that there are no unit tests, but do you use some other tool to test the parts involving *context.Context?

Regards,

[unknwon]

Hey @ivis-kuwata!

I'm wondering why there are no unit tests defined for functions that take *context.Context struct as an argument, in the internal/route/repo directory etc..

Very valid question, and a real problem indeed. It is very hard to mock a pointer struct in Go.

Speaking from my potential approach if I ever get chance to refactor the entire router layer 😅, I would convert the current *context.Context to an interface context.Context, which then becomes much easier to articulate mock states with mock implementations of the context.Context. https://github.com/derision-test/go-mockgen is the one I've used in other project to generate ergonomic mocks for interfaces.

For testing API endpoints, my thinking is that, since all of these endpoints speak JSON, it is a good opportunities to actually do integration tests instead of unit tests (of course, more unit tests here won't hurt), do real business logic, hit the real database, etc.

Hope this helps and happy to dig into more on this with you!

[ivis-kuwata]

@unknwon
Thanks for getting back to me! Actually, I tried to convert the current *context.Context to an interface context.Context. To do this, I used https://github.com/sanposhiho/gomockhandler that created by the Japanese development team. This gomockhandler can manage our mocks in one config file.

However, as we proceeded with the conversion and unittest implementation, we realized that some other library modifications may also be necessary, and we are now suspending the conversion due to time constraints.
(e.g. git-module.Blob that returns a pointer struct *Blob)

We, also, are willing to discuss this issue on an ongoing basis.

[unknwon]

For the git-module thing specifically, I actually has made some progress some time ago to mock out the almost entire functionality of what it does for easier unit testing, you can take a look at these files:

• https://github.com/gogs/gogs/blob/main/internal/gitutil/module.go
• https://github.com/gogs/gogs/blob/main/internal/gitutil/mocks.go

And how it is used to do the actual test: https://github.com/lfuelling/ntGogs/blob/main/internal/gitutil/pull_request_test.go