Should you be using "go test" ?

go test

Is the built in unit testing library for go.  Like any language, its usually idiomatic and smart to use libraries that are already available, rather than building your own.

However

Remember that golang is a language with a rapidly growing ecosystem, but nevertheless, a language whose core is meant to remain small and simple.  This means that for large, highly dynamic applications, some of the native tooling may not evolve fast enough.

Advantages of go test over a regular application

Go test comes with alot of features which are GREAT for unit tests.  Detecting race conditions, assertion statements, and so on.  For unit tests, there is nothing better .  If you want declarative testing, you can use wrappers like ginkgo.

BUT im not sure i would use it for larger application suites, performance suites, and so on.
 
However, when it comes to flexibility, ESPECIALLY when it comes to flags (see my other post http://jayunit100.blogspot.com/2016/09/viper-go-flag-and-pflag-how-they.html) you could run into issues.

Concretely,

• many applications use glog as their logging library, these apps will lose out when wrapped in go test.  go test has its own logging implementation, and the options and configuration might  collide.
• many applications use pflag or viper:  go test however uses "go flag"

Context : Other languages and logging

Compared with a language like java (which has runtime logging library bindings, like slf4j - see my post on that - http://jayunit100.blogspot.com/2013/10/simplifying-distinction-between-sl4j.html, which can be used and fully configured at the application tier and are totally dynamic), some of go tests functionality is restrictive.

Similarly, Python logging is fully configurable (https://docs.python.org/2.7/library/logging.config.html).   And intercepting to the Logger even allows you to unit test the logs.


In general, I think other langauges have a much more logging and configuration basis which is used via testing frameworks, and thus you can build richer "test-ish" applications on top of them. 

My suggestion?  In 2016, If your building performance suites or large test suites for a distributed system, roll your own - the unit test features in go test probably wont get used much, and the restrictions (like logging conflicts, flag conflicts, etc) will bite you.

If this ever changes, or maybe I'm missing something, and someone reads this post and proves otherwise, I'll update the post :).