Preferred form of modification for binary data used in unit testing?

[Philipp Hahn <pmhahn@pmhahn.de>]

Hi,

if a *previous* version of a software generated a *buggy* binary
database, that bug got fixed in a *newer* version and also some
*recovery* mechanism was added to allow reading that broken format
*once*, but there is no code the write the *broken* file again. For
*unit testing* the upstream developers added an *example* of such a
broken database to their test data.
What's the preferred form of modification for that data set?

* Should I include a copy of the *broken code* to generate that data?
* Declare that there in no preferred form for modification, as a
"open-save"-cycle with the current code will not re-create the bit
idencial file again.
* Remove the test data because it is not DFSG conformant and hope the
Debian build will never break the recovery code.
* Include instructions on how to re-build the broken version and give
instructions on how to maybe rebuild a similar broken file.

Philipp

PS: This question is motivated while working on a private build of
> E: keepassxc source: source-is-missing tests/data/keepassxc.opvault/default