Small fixes to syntax
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 32935ec..5a475af 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,5 +1,10 @@
# Contributing to gophercloud
+- [Getting started](#getting-started)
+- [Tests](#tests)
+- [Style guide](#basic-style-guide)
+- [4 ways to get involved](#4-ways-to-get-involved)
+
## Getting started
There should be no fundamental differences of setup between contributors and
@@ -33,17 +38,16 @@
"github.com/rackspace/gophercloud/testhelper"
)
-
func TestSomething(t *testing.T) {
- testhelper.AssertEquals(t, "expected", "actual")
-}
-
-func TestErrors(t *testing.T) {
result, err := Operation()
testhelper.AssertEquals(t, "foo", result.Bar)
testhelper.AssertNoErr(t, err)
}
+
+func TestSomethingElse(t *testing.T) {
+ testhelper.CheckEquals(t, "expected", "actual")
+}
```
`AssertEquals` and `AssertNoErr` will throw a fatal error if a value does not
@@ -53,7 +57,7 @@
Here is a truncated example of mocked HTTP responses:
-```
+```go
import (
"testing"
@@ -62,21 +66,22 @@
)
func TestGet(t *testing.T) {
+ // Setup the HTTP request multiplexer and server
th.SetupHTTP()
defer th.TeardownHTTP()
th.Mux.HandleFunc("/networks/d32019d3-bc6e-4319-9c1d-6722fc136a22", func(w http.ResponseWriter, r *http.Request) {
// Test we're using the correct HTTP method
- th.TestMethod(t, r, "GET")
+ th.TestMethod(t, r, "GET")
- // Test we're setting the auth token
+ // Test we're setting the auth token
th.TestHeader(t, r, "X-Auth-Token", fake.TokenID)
- // Set the appropriate headers for our mocked response
+ // Set the appropriate headers for our mocked response
w.Header().Add("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
- // Set the HTTP body
+ // Set the HTTP body
fmt.Fprintf(w, `
{
"network": {
@@ -91,21 +96,21 @@
`)
})
- // Call our API operation
+ // Call our API operation
network, err := Get(fake.ServiceClient(), "d32019d3-bc6e-4319-9c1d-6722fc136a22").Extract()
- // Assert no errors and equality
+ // Assert no errors and equality
th.AssertNoErr(t, err)
th.AssertEquals(t, n.Status, "ACTIVE")
}
```
-### Acceptance tests + build tags
+### Acceptance tests
As we've already mentioned, unit tests have a very narrow and confined focus -
they test small units of behaviour. Acceptance tests on the other hand have a
far larger scope: they are fully functional tests that test the entire API of a
-service in one fell swoop. They don't care about unit independence or mocking
+service in one fell swoop. They don't care about unit isolation or mocking
expectations, they instead do a full run-through and consequently test how the
entire system _integrates_ together. When an API satisfies expectations, it
proves by default that the requirements for a contract have been met.
@@ -170,24 +175,24 @@
We have three forms of documentation:
* short README documents that briefly introduce a topic
-* reference documentation on [godoc.org](http://godoc.org) that automatically
-generates from source code comments
+* reference documentation on [godoc.org](http://godoc.org) that is automatically
+generated from source code comments
* user documentation on our [homepage](http://gophercloud.io) that includes
getting started guides, installation guides and code samples
If you feel that a certain section could be improved - whether its to clarify
-ambiguity or a fix a grammatical mistake - please feel entitled to do so! We
+ambiguity or fix a grammatical mistake - please feel entitled to do so! We
welcome doc pull requests with the same childlike enthusiasm as any other
contribution!
### 3. Optimizing existing features
If you would like to improve or optimize an existing feature, please be aware
-that we adhere to semantic versioning] - which means that we cannot introduce
-breaking changes to the API without a major version change (v1.x -> v2.x).
-Making that leap is a big step, so we encourage contributors to refactor rather
-than rewrite. Running tests will prevent regression and avoid the possibility
-of breaking somebody's current implementation.
+that we adhere to [semantic versioning](http://semver.org) - which means that
+we cannot introduce breaking changes to the API without a major version change
+(v1.x -> v2.x). Making that leap is a big step, so we encourage contributors to
+refactor rather than rewrite. Running tests will prevent regression and avoid
+the possibility of breaking somebody's current implementation.
### 4. Working on a new feature
@@ -199,4 +204,6 @@
You must ensure that all of your work is well tested - both in terms of unit
and acceptance tests. Untested code will not be merged because it introduces
-too much of a risk to end-users. Happy hacking!
+too much of a risk to end-users.
+
+Happy hacking!