Consider test helper functions for a streamlined testing development cycle
prestist opened this issue · comments
Feature Request
When looking at the tests found under the types
of each schema
there are some things that could benefit from a better test writing process.
Reduce the code duplication
The code duplication presents its self as anonymous structs like the following
tests =: [] struct {
in : structUnderTest,
out: expectedOutput
}
As well as the section that executes the code, and verifies the expected output, this is usually in a form similar to this:
for i, test := range tests {
r := test.in.Validate(path.ContextPath{})
expected := report.Report{}
expected.AddOnError(path.New(""), test.out)
if !reflect.DeepEqual(expected, r) {
t.Errorf("#%d: bad report: want %v got %v", i, test.out, r)
}
}
Recommended fix
This can be extracted into a helper go utility. The utility would need to be generalized to take in the correct input, and expected output. However, we would also be able to build on top of it, following a builder pattern . This should help encourage a streamlined development cycle for tests that should be expandable as needs come up.
Reduce need to explain tests
When looking at the tests they generally are grouped under a section of functionality. Take a look at the following code:
func TestStorageValidateErrors(t *testing.T) {
tests := []struct {
in Storage
at path.ContextPath
out error
}{
{
in: Storage{},
out: nil,
},
{
in: Storage{
Links: []Link{
{
Node: Node{Path: "/foo"},
},
{
Node: Node{Path: "/quux"},
},
},
Files: []File{
{
Node: Node{Path: "/bar"},
},
},
Directories: []Directory{
{
Node: Node{Path: "/baz"},
},
},
},
out: nil,
},
...
{
in: Storage{
Links: []Link{
{
Node: Node{Path: "/quux"},
LinkEmbedded1: LinkEmbedded1{
Target: "/foo/bar",
Hard: util.BoolToPtr(true),
},
},
},
Directories: []Directory{
{
Node: Node{Path: "/foo/bar"},
},
},
},
out: errors.ErrHardLinkToDirectory,
at: path.New("", "links", 0),
},
}
Recommended fix
Here there are a fairly large number of tests packed in this anonymous struct and they have no description, this tends to require the person writing the test to add comments describing the test or the reader to understand the nature of the tests. This is in part because the test function is TestStorageValidateErrors
; while, yes we are testing this, we also have the opportunity to make the test more explicit in what its testing. So in being more specific in what we are testing we in turn reduce the need for comments and let the code describe it's self. This could be done by adding a description field on the test struct or split each unit under test into its own test function. While the former has the reduction of functions, the latter has the improved debugging experience.