Same as |assert_logs_eq_to_golden|, except an additional filtering function may be used to trim
arbitrary logs. This is particularly useful if one or more languages produces logs that we don’t
want to include in the final, common output to be compared across language implementations.
Takes the logs for a single component and compares them to the appropriate golden file. The path
of the file is expected to match the template /pkg/data/goldens/{COMPONENT_NAME}.log.golden.
The {COMPONENT_NAME} is itself generally a template of the form {TEST_NAME}_{COMPONENT_ROLE}.
Thus, for the three-component test_foo_bar, we expect the following golden logs to exist:
Takes a vector of raw logs, and returns an iterator over the string representations of said
logs. The second argument allows for optional filtering by component. For example, if one only
wants to see server logs, the invocation may look like:
Same as |logs_to_str|, except an additional filtering function may be used to trim arbitrary
logs. This is particularly useful if one or more languages produces logs that we don’t want to
include in the final, common output to be compared across language implementations.
Runs a test of the specified protocol, using one of the TestKinds enumerated above. The
input_setter closure may be used to pass structured config values to the client, which is how
the test is meant to receive its inputs. The logs_reader closure provides the raw logs
collected from all child processes under test, allowing test authors to assert against the
logged values. Note that these are raw logs - most users will want to process the logs into
string form, which can be accomplished by passing the raw log vector to the logs_to_str helper
function.