|
| 1 | +# Tester: Test More, Type Less |
| 2 | +Lightweight test utilities to use with Go's testing package. |
| 3 | + |
| 4 | +## Features |
| 5 | +* Assertions that make testss easier to read, write, and debug |
| 6 | +* Streamlined data providers for data-driven testing (DDT) |
| 7 | +* Test hooks' hygiene check |
| 8 | + |
| 9 | +## Motivations |
| 10 | +Most tests follow the same pattern: set up, invoke the unit under test, assert, |
| 11 | +then clean up (if need be); said pattern encourages code reuse and consistency. |
| 12 | +By using test utilities, you can spend more time thinking about test stratigies |
| 13 | +and less time typing boilerplate code. |
| 14 | + |
| 15 | +## Quick Start |
| 16 | +Get the latest version (`go get -u github.com/workfit/tester`) then test away: |
| 17 | + |
| 18 | + package hitchhiker |
| 19 | + |
| 20 | + import ( |
| 21 | + "testing" |
| 22 | + "github.com/workfit/tester/assert" |
| 23 | + ) |
| 24 | + |
| 25 | + func TestDeepThought(t *testing.T) { |
| 26 | + computer := NewDeepThoughtComputer() |
| 27 | + answer, err := computer.AnswerTheUltimateQuestion() |
| 28 | + if assert.For(t).ThatActual(err).IsNil().Passed() { |
| 29 | + assert.For(t).ThatActual(answer).Equals(42) |
| 30 | + } |
| 31 | + } |
| 32 | + |
| 33 | +## Learn More |
| 34 | +The following can be also found at <https://godoc.org/github.com/workfit/tester> |
| 35 | + |
| 36 | +### Assertions |
| 37 | +Package `assert` provides a more readable way to assert in test cases; |
| 38 | +for example: |
| 39 | + |
| 40 | + assert.For(t).ThatCalling(fn).PanicsReporting("expected error") |
| 41 | + |
| 42 | +This way, the assert statement reads well; it flows like a proper sentence. |
| 43 | + |
| 44 | +In addition, one can easily tell which value is the test case got (actual) |
| 45 | +and which it wanted (expected); this is key to printing the values correctly |
| 46 | +to make debugging a bit easier. In Go, the actual value is usually printed |
| 47 | +first; for example: |
| 48 | + |
| 49 | + assert.For(t).ThatActual(foo).Equals(expected) |
| 50 | + |
| 51 | +The above enforces said order in both reading the code and the assertion failure |
| 52 | +message (if any). |
| 53 | + |
| 54 | +For convenience (that also improves readability), there are methods for special |
| 55 | +cases like: |
| 56 | + |
| 57 | + assert.For(t).ThatActual(foo).IsTrue() |
| 58 | + assert.For(t).ThatActualString(bar).IsEmpty() |
| 59 | + |
| 60 | +Which are equivalent to: |
| 61 | + |
| 62 | + assert.For(t).ThatActual(foo).Equals(true) |
| 63 | + assert.For(t).ThatActual(len(bar)).Equals(0) |
| 64 | + |
| 65 | +To identify a test case in a table-driven test, optional ID parameters can be |
| 66 | +specified and will be included in failure messages: |
| 67 | + |
| 68 | + cases := []struct { |
| 69 | + id string |
| 70 | + actual interface{} |
| 71 | + expected interface{} |
| 72 | + }{ |
| 73 | + {"different values", 42, 13}, |
| 74 | + {"different types", 42.0, 42}, |
| 75 | + {"different containers", [...]int{42}, []int{42}}, |
| 76 | + } |
| 77 | + |
| 78 | + for _, c := range cases { |
| 79 | + assert.For(t, c.id).ThatActual(c.actual).Equals(c.expected) |
| 80 | + } |
| 81 | + |
| 82 | +After an assertion is performed, a `ValueAssertionResult` is returned to allow |
| 83 | +for post-assert actions to be performed; for example: |
| 84 | + |
| 85 | + assert.For(t).ThatActual(value).Equals(expected).ThenDiffOnFail() |
| 86 | + |
| 87 | +Which will pretty-print a detailed recursive diff of both objects on failure. |
| 88 | + |
| 89 | +It also can be used as a condition to perform extra test steps: |
| 90 | + |
| 91 | + value := GetValue() |
| 92 | + if assert.For(t).ThatActual(value).IsNotNil().Passed() { |
| 93 | + assert.For(t).ThatActual(value.GetFoo()).Equals(expected) |
| 94 | + } |
| 95 | + |
| 96 | +Or to perform a deeper analysis of the test values: |
| 97 | + |
| 98 | + if !assert.For(t).ThatActual(value).Equals(expected).Passed() { |
| 99 | + analyze(value, expected) // e.g., analyze may look at common bugs |
| 100 | + } |
| 101 | + |
| 102 | +Conveniently, the last example above can be rewritten as: |
| 103 | + |
| 104 | + assert.For(t).ThatActual(value).Equals(expected).ThenRunOnFail(analyze) |
| 105 | + |
| 106 | +Another use is to print a custom failure message: |
| 107 | + |
| 108 | + assert.For(t).ThatActual(foo).Equals(bar).ThenRunOnFail(func(actual, expected interface{}) { |
| 109 | + fmt.Printf("JSON: %q != %q", actual.ToJSON(), expected.ToJSON()) |
| 110 | + }) |
| 111 | + |
| 112 | +The above pattern allows for reuse of post-failure analysis and cleanup. |
| 113 | + |
| 114 | +The interfaces in this package are still a work-in-progress, and are subject |
| 115 | +to change. |
| 116 | + |
| 117 | +### Test Hooks |
| 118 | +What exists merely for test code to see shall not be exported to the world. |
| 119 | +You can tag test-hook fields like the following: |
| 120 | + |
| 121 | + type sleeper struct { |
| 122 | + sleep func(time.Duration) `test-hook:"verify-unexported"` |
| 123 | + } |
| 124 | + |
| 125 | +Using tags, instead of comments, enables you to search the codebase for test |
| 126 | +hooks and validate, via reflection, that they're not exported. |
| 127 | +A test case should be added to verify that test hooks are hidden: |
| 128 | + |
| 129 | + func TestHooksAreHidden(t *testing.T) { |
| 130 | + assert.For(t).ThatType(reflect.TypeOf(sleeper{})).HidesTestHooks() |
| 131 | + } |
| 132 | + |
| 133 | +### Data-Driven Testing (DDT) |
| 134 | +When the number of test cases in a table-driven test gets out of hand and they |
| 135 | +cannot fit neatly in structs anymore, the use of a data provider is in order. |
| 136 | +Package `ddt` provides a way to load test cases from a JSON file whose path |
| 137 | +is derived from the caller's test function name and file. The file path is |
| 138 | +`<package under test>/_ddt/<basename of test file>.json`; for example, |
| 139 | +`hitchhiker/_ddt/question_test.json` with the following schema: |
| 140 | + |
| 141 | + { |
| 142 | + "testFunctions": { |
| 143 | + "<name of test function>": [ |
| 144 | + { |
| 145 | + <properties of the test case to unmarshal> |
| 146 | + } |
| 147 | + ] |
| 148 | + } |
| 149 | + } |
| 150 | + |
| 151 | +For example, the JSON content may look like the following: |
| 152 | + |
| 153 | + { |
| 154 | + "testFunctions": { |
| 155 | + "TestDeepThought": [ |
| 156 | + { |
| 157 | + "id": "The Ultimate Question", |
| 158 | + "input": { |
| 159 | + "question": "What do you get when you multiply six by nine?", |
| 160 | + "timeoutInHours": 65700000000, |
| 161 | + "config": {"base": 13} |
| 162 | + }, |
| 163 | + "expected": { |
| 164 | + "answer": "42", |
| 165 | + "error": null |
| 166 | + } |
| 167 | + } |
| 168 | + ] |
| 169 | + } |
| 170 | + } |
| 171 | + |
| 172 | +The details of the test case struct are left for the tester to specify. |
0 commit comments