Change made by: - running "gvt fetch" on each of the packages mentioned in Godeps/Godeps.json - `rm -rf Godeps` - tweaking the build scripts to not mention Godeps - tweaking the build scripts to test `./lib/...`, `./cmd/...` explicitly (to avoid testing vendor) - tweaking the build scripts to not juggle GOPATH for Godeps and instead set GO15VENDOREXPERIMENT. This also results in some updated packages at the same time I bet. Building with Go 1.3 and 1.4 still *works* but won't use our vendored dependencies - the user needs to have the actual packages in their GOPATH then, which they'll get with a normal "go get". Building with Go 1.6+ will get our vendored dependencies by default even when not using our build script, which is nice. By doing this we gain some freedom in that we can pick and choose manually what to include in vendor, as it's not based on just dependency analysis of our own code. This is also a risk as we might pick up dependencies we are unaware of, as the build may work locally with those packages present in GOPATH. On the other hand the build server will detect this as it has no packages in it's GOPATH beyond what is included in the repo. Recommended tool to manage dependencies is github.com/FiloSottile/gvt.
6.7 KiB
Jump to the docs to learn more. To start rolling your Ginkgo tests now keep reading!
To discuss Ginkgo and get updates, join the google group.
Feature List
-
Ginkgo uses Go's
testing
package and can live alongside your existingtesting
tests. It's easy to bootstrap and start writing your first tests -
Structure your BDD-style tests expressively:
- Nestable
Describe
andContext
container blocks BeforeEach
andAfterEach
blocks for setup and teardownIt
blocks that hold your assertionsJustBeforeEach
blocks that separate creation from configuration (also known as the subject action pattern).BeforeSuite
andAfterSuite
blocks to prep for and cleanup after a suite.
- Nestable
-
A comprehensive test runner that lets you:
- Mark specs as pending
- Focus individual specs, and groups of specs, either programmatically or on the command line
- Run your tests in random order, and then reuse random seeds to replicate the same order.
- Break up your test suite into parallel processes for straightforward test parallelization
-
ginkgo
: a command line interface with plenty of handy command line arguments for running your tests and generating test files. Here are a few choice examples:ginkgo -nodes=N
runs your tests inN
parallel processes and print out coherent output in realtimeginkgo -cover
runs your tests using Golang's code coverage toolginkgo convert
converts an XUnit-styletesting
package to a Ginkgo-style packageginkgo -focus="REGEXP"
andginkgo -skip="REGEXP"
allow you to specify a subset of tests to run via regular expressionginkgo -r
runs all tests suites under the current directoryginkgo -v
prints out identifying information for each tests just before it runs
And much more: run
ginkgo help
for details!The
ginkgo
CLI is convenient, but purely optional -- Ginkgo works just fine withgo test
-
ginkgo watch
watches packages and their dependencies for changes, then reruns tests. Run tests immediately as you develop! -
Built-in support for testing asynchronicity
-
Built-in support for benchmarking your code. Control the number of benchmark samples as you gather runtimes and other, arbitrary, bits of numerical information about your code.
-
Completions for Sublime Text: just use Package Control to install
Ginkgo Completions
. -
Straightforward support for third-party testing libraries such as Gomock and Testify. Check out the docs for details.
-
A modular architecture that lets you easily:
- Write custom reporters (for example, Ginkgo comes with a JUnit XML reporter and a TeamCity reporter).
- Adapt an existing matcher library (or write your own!) to work with Ginkgo
Gomega: Ginkgo's Preferred Matcher Library
Ginkgo is best paired with Gomega. Learn more about Gomega here
Agouti: A Golang Acceptance Testing Framework
Agouti allows you run WebDriver integration tests. Learn more about Agouti here
Set Me Up!
You'll need Golang v1.3+ (Ubuntu users: you probably have Golang v1.0 -- you'll need to upgrade!)
go get github.com/onsi/ginkgo/ginkgo # installs the ginkgo CLI
go get github.com/onsi/gomega # fetches the matcher library
cd path/to/package/you/want/to/test
ginkgo bootstrap # set up a new ginkgo suite
ginkgo generate # will create a sample test file. edit this file and add your tests then...
go test # to run your tests
ginkgo # also runs your tests
I'm new to Go: What are my testing options?
Of course, I heartily recommend Ginkgo and Gomega. Both packages are seeing heavy, daily, production use on a number of projects and boast a mature and comprehensive feature-set.
With that said, it's great to know what your options are :)
What Golang gives you out of the box
Testing is a first class citizen in Golang, however Go's built-in testing primitives are somewhat limited: The testing package provides basic XUnit style tests and no assertion library.
Matcher libraries for Golang's XUnit style tests
A number of matcher libraries have been written to augment Go's built-in XUnit style tests. Here are two that have gained traction:
You can also use Ginkgo's matcher library Gomega in XUnit style tests
BDD style testing frameworks
There are a handful of BDD-style testing frameworks written for Golang. Here are a few:
Finally, @shageman has put together a comprehensive comparison of golang testing libraries.
Go explore!
License
Ginkgo is MIT-Licensed