You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
Feature Request
When looking at the tests found under the
types
of eachschema
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
As well as the section that executes the code, and verifies the expected output, this is usually in a form similar to this:
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:
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.The text was updated successfully, but these errors were encountered: