-
Notifications
You must be signed in to change notification settings - Fork 882
Description
Is your feature request related to a problem? Please describe.
Frequently we encounter bugs with our mapping code from a request to an internal type. Our primary method of testing these mappers is to write a round trip test with hardcoded sanity values for the structs that are being tested. Whenever a new field is added to an external type, the corresponding test(s) need to be updated. However this only tests 1 of the 3 ways that things could fail:
Neither mapper implements the type (this is not tested - tests will pass)
Only one mapper implements the type (round trip fails)
Both mappers implement the type
One mapper implements it incorrectly (round trip fails)
Both mappers implement it in converse (round trip succeeds - tests will pass)
The most common type of error is in the differences between code generated from proto and thrift handling nil types differently.
Proposed Solution
To adequately test our mappers we should be able to test a wide range of data. Hardcoding the list of possible values is prohibitively difficult, particularly with the permutations of a given struct. We have solved this problem in the go-client by adding gofuzz tests. These tests randomly assign values to each member of the struct (including nils) and tests the conversion functions.
This should be added to tests of all of our mappers within the go server.
Additional context
N/A