Ginkgo is the testing framework that we use for writing our test cases. It helps us write expressive testing specifications, organize our tests into well-defined categories, and describe expected behavior cleanly within each test.
Before proceeding, we recommend reading through the basic tests in client_test.go, especially the first few ones, since those are well-documented in-line. Then, come back to this documentation.
You should be able to write most of your tests using some combination of calls to –
- Initialization methods (e.g.
- User-specific methods (e.g.
- Declarations of expected behavior (e.g.
To assert expected behavior, you may want to check (a) that an error did or didn’t occur, and/or (b) that some data was what you expected it to be. For example:
// Check that an error didn't occur alice, err := client.InitUser("alice", "password") Expect(err).To(BeNil()) // Check that an error didn't occur err = alice.StoreFile("alice.txt", byte("hello world")) Expect(err).To(BeNil()) // Check that an error didn't occur AND that the data is what we expect data, err := alice.LoadFile("alice.txt") Expect(err).To(BeNil()) Expect(data).To(Equal(byte("hello world"))) // Check that an error DID occur data, err := alice.LoadFile("rubbish.txt") Expect(err).ToNot(BeNil())
You can organize tests using some combination of
Describe(...) containers, with tests contained within
Specify(...) blocks. The more organization you have, the better! Read more about how to organize your tests here.
To measure and visualize local test coverage (e.g. how many lines of your implementation your test file hits), you can run these commands in the root folder of your repository:
go test -v -coverpkg ./... ./... -coverprofile cover.out go tool cover -html=cover.out
Coverage over your own implementation may serve as an indicator for how well your code will perform (with regards to coverage flags) when compared to the staff implementation! It should also help you write better unit testing to catch edge cases.