A small style (self-thinking) guide to Go testing. The article about writing good tests is much more than I wrote here. But I'm writing about style, not technology. # # Use the table-drive test, and always use TT as a test case to try to use the Table-driven test if feasible, but when it is not available, you can copy some code; Do not force it (for example, sometimes in addition to one or two cases, It is easier to write a Table-driven test for a situation other than this, as is the case in reality. Always using the same variable name for a test case makes it easier to work with a lot of code. You do not have to use TT, but it is the most commonly used in the Go standard library (564 times compared with TC 116 times). You can look at [tabledriventests] (https://github.com/golang/go/wiki/TableDrivenTests). For example: "' gotests: = []struct {//...} {}for _, TT: = range Tests {} ' # # # using a sub-test you can run a separate test from a table, and it's easy to see which test failed completely. Because the sub-tests are relatively new versions (Go 1.7, October 2016), many existing tests cannot use them (sub-tests). If the test content is obvious, I prefer to simply use the test number, or add a test name if it is not obvious or there are many test cases. You can look at [using sub-test and sub-datum] (https://blog.golang.org/subtests) For example: ' gotests: = []struct {//...} {}for I, TT: = Range Tests {t.run (FMT. Sprintf ("%d", I), func (t *testing). T) {Got: = TestFunction (tt.input) if got! = tt.want {T.errorf ("failed for%v ...", Tt.input)}})} "# # Don't ignore the error I often see someone ignoring the error in the test 。 This is a bad idea and makes the failed test confusing. For example: ' Gogot, err: = Fun () If err! = Nil {t.fatalf ("Unexpected error:%v", err)} ' or: ' Gogot, err: = Fun () if err! = Tt.wa Nterr { T.fatalf ("Wrong error\ngot:%v\nwant:%v", Err, Tt.wanterr)} ' I often use [errocontains] (https://github.com/Teamwork/test /BLOB/859EDA3CD87ED7713DF79C5BB2B2A90601AD0524/TEST.GO#L13-L26), it is a useful help function to test error messages (avoid some ' if err! = Nil && [ ..] ) # # Check your tests as regular code test code will also fail, error, so need maintenance. If you think running Linter is worthwhile for your regular code, it's just as rewarding for your test run. (ex: Go vet, Errcheck, etc.). # # Use want and gotwant shorter than expected, got shorter than actual. Short naming always has an advantage, IMHO, and is particularly advantageous for aligning the output (see the example below). For example: ' gocases: = []struct {want string Wantcode int}{} ' # # Add useful, aligned information when a test failure is accompanied by a useless error message, or a confusing error message, It is annoying to make it difficult to see the exact error. This is not particularly useful: "' got. Errorf ("Wrong output:%v", got) "When the test fails, it tells us to get the error output, but what do we want to get?" This is better: "' goname: =" Test Foo "Got: =" This string! " Want: = "This string" T.errorf ("wrong output for%v, want%v; Got%v ", name, got, Want)" This is hard to see the exact failure: '---fail:testx (0.00s) A_test.go:9: Wrong output for test foo, want this Stri ng!; Got this string ' when aligning it, it is easy: ' goname: = ' Test foo ' want: = ' This string ' T.run (name, func (t *testing. T) {got: = "this string!" T.Errorf ("Wrong output\ngot:%q\nwant:%q", Got, Want)}) ""---fail:testx (0.00s)---fail:testx/test_foo (0.00s) a_test . Go:10:wrong Outputgot: "This string!" Want: "This string" ' Note ' Got: ' After the two spaces, is to be aligned with ' want '. If I use ' expected ' I will use 6 spaces. I also prefer to use '%q ' or '% #v ' as this will clearly show the following blank or non-printable characters. Use diff to compare larger objects, for example with [go-cmp] (https://github.com/google/go-cmp): ' goif D: = cmp. Diff (got, tt.want); D! = "" {T.errorf ("(-got +want) \n:%s", D)} ""---fail:testparsefilter (0.00s)---fail:testparsefilter/alias (0.00s) Q uery_test.go:717: (-got +want): {Jsonapi. Filter}. alias:-: "Fail" +: "Alias" ' # # Figuring out what to test sometimes I see some tests, I'm confused "what is this testing?" "This can be particularly confusing if the cause of the test failure is not named." Where should I change it? Did you test it correctly? For example: ' gocases: = []struct {name string}{{' space after @ ',},{' Unicode space before @ ',},//...} "If adding ' name ' to the existing test case must be more useful than commenting." # # Feedback You can e-mail me: [Martin@arp242.ent] (martin@arp242.net) or [Submit a GitHub question] (https://github.com/Carpetsmoker/arp242.net /issues/new) Feedback, ask questions and so on.
Via:https://arp242.net/weblog/go-testing-style.html
Author: Martin Tournoij Translator: themoonbear proofreading: polaris1119
This article by GCTT original compilation, go language Chinese network honor launches
This article was originally translated by GCTT and the Go Language Chinese network. Also want to join the ranks of translators, for open source to do some of their own contribution? Welcome to join Gctt!
Translation work and translations are published only for the purpose of learning and communication, translation work in accordance with the provisions of the CC-BY-NC-SA agreement, if our work has violated your interests, please contact us promptly.
Welcome to the CC-BY-NC-SA agreement, please mark and keep the original/translation link and author/translator information in the text.
The article only represents the author's knowledge and views, if there are different points of view, please line up downstairs to spit groove
119 Reads
