h1. Unit Testing Libraries
h2. testing (standard library)
* Package testing provides support for automated testing of Go packages. It is intended to be used in concert with the “go test” command, which automates execution of any function of the form.
* Documentation: https://golang.org/pkg/testing/
* Pros:
* * Easy to use.
* Native Go library so we do not need to install additional unofficial dependencies.
* Boiler plate code can be generated in Visual Studio Code
* A lot of examples and documentation available.
* Cons:
* More verbose than using a 3rd part library like [stretchr/testify|https://github.com/stretchr/testify]
* Doesn't provide mocking functionality out of the box.
* Additional links:
* https://blog.alexellis.io/golang-writing-unit-tests/
h2. testify
* Documentation: [stretchr/testify|https://github.com/stretchr/testify]
* Supports Go 1.11
* Pros:
* Easy to use and implements the familiar Assert style seen in other languages
* Extends the standard Go testing library so both can be used interchangeably
* Provides a mocking mechanism
* Partially used in other Aerogear projects ([aerogear-app-metrics|https://github.com/aerogear/aerogear-app-metrics]
* Cons:
* Seems unnecessary since the standard library can do the same things just in a different way. This just lightly wraps the standard library
* 3rd party dependency not officially supported by Go.
* The standard Go testing library deliberately doesn't use assertions. The authors of [The Go Programming Language|https://github.com/KeKe-Li/book/blob/master/Go/The.Go.Programming.Language.pdf] make some good arguments for Go's style over Assertions. See Page 302.
* Tests can feel like they're written in a different language (RSpec/Mocha for instance)
* Errors can be cryptic "assert: 0 == 1"
* Pages of stack traces can be generated
* Tests stop executing after the first assert fails - masking patterns of failure
|
|
