Fine-grained testing of config file parser with many mandatory fields

I'm writing a serde/TOML parser for config files I need for an application.

There are a number of mandatory fields. I want to test the parser thoroughly. This leads to conflicting pressures:

  • I want the parser to fail to parse any config file which omits any field whose type is not Option<_>,
  • I want to be able to write fine-grained tests about the how individual fields (or small groups of related fields) are parsed.

The failure to parse inputs with missing fields is pushing me to inject them as noise in the fine-grained test case data.

Can you suggest a way of reconciling these opposing pressures?

Is there some switch which would relax the requirement that non-Option fields be present, without modifying the definition of the struct being parsed?

There's this:

#[serde(default = "path")]

When deserializing, any missing fields should be filled in from the object returned by the given function or method. [...]

Maybe provide two definitions of path, one behind #[cfg(test)] which succeeds silently, and another behing #[cfg(not(test))] which errors?

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.