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

[Steve McIntyre <steve@einval.com>]

Hey Philipp,

Philipp Hahn wrote:
>
>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.

Firstly, removing the test data would be absurd - less-tested code
does not serve us or our users well. If it happens to be a binary
artifact that cannot be easily recreated, then explain that. The
binary artifact has become the preferred form for modification once
you have it.

In some cases you won't be able to sensibly reproduce the artifact
that causes a problem, but you keep it around to ensure test
coverage. IMHO there is no issue here.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane