Many thanks Chris, that's a wonderful idea and I've successfully got rid of
the test mode flags!
On Tuesday, 25 July 2017 05:47:30 UTC+2, Chris Broadfoot wrote:
>
> One way around the flag problem is to accept an interface, instead of
> using testing.T.
>
> Watch Mitchell Hashimoto's talk from
I haven't got the context but I agree that importing the testing package
outside of a test is a very bad idea. If I could, I would disallow it
altogether.
-rob
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
One way around the flag problem is to accept an interface, instead of using
testing.T.
Watch Mitchell Hashimoto's talk from GopherCon from about 39m30s:
https://youtu.be/8hQG7QlcLBk?t=2368
http://github.com/mitchellh/go-testing-interface
On Mon, Jul 24, 2017 at 1:44 AM, roger peppe
On 24 July 2017 at 09:12, Howard Guo wrote:
> Thanks Nigel! I should definitely consider improving the test case.
>
> Go compiler appears to automatically places test flags into executable
> whenever "testing" package is included - no matter the function using
> "testing"
Thanks Nigel! I should definitely consider improving the test case.
Go compiler appears to automatically places test flags into executable
whenever "testing" package is included - no matter the function using
"testing" package is dead code or otherwise. So here's a bug report for go:
On Sat, Jul 22, 2017 at 7:08 PM, Howard Guo wrote:
> https://github.com/HouzuoGuo/laitos
It's tangential to your question, but out of curiousity, I skimmed the
source code. In things like func TestUDPServer in
Just to clarify: Jan showed that you import the "testing" package, not just
from ..._test.go files.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to