Story Time

• As an rpmautospec developer,
  I want to have test data for different git histories of a package,
  so that we can test our code against them.

• As an rpmautospec developer,
  I want to have such testing histories defined "near" the code of the tests themselves,
  so I'm not confused about what the expected results of processing them are.

Acceptance Criteria

• A framework exists which lets us describe test cases—i.e. package repositories with histories exhibiting certain peculiarities we want to test—and, from these descriptions, can synthesize these testing repositories for tests to process.
• This framework is used to test calculating the release number for these cases:
  • a plain linear history, nothing special
  • the spec file containing weirdly encoded data at some point in history (old packages often used ISO-8859 rather than UTF-8 to encode characters outside of the ASCII range)
  • the spec file being absent at some point in history (e.g. the root commit, often package repositories are created with only just a README in there so we have to cope with it)

Background

Right now, tests/test-data/repodata/ has one tarball of a package repository and a file containing what is expected when the contained spec file (with the history) is processed, i.e. one test case. This way is pretty opaque when you write new tests or edit existing ones, because the tarball is unpacked into a temporary place, the tests are run on it the unpacked repo is deleterd when done, i.e. it's not obvious what test data is processed. Also, it's not that easy to change if needed.

David and I racked our brains over discrepancies between the results we expected and what we actually got for the release bumping algorithm, it was off by one or two and we thought there was a bug in the code being tested, rather than that the tarball had "more" history to it than the age-old unpacked copy I had lying around. Explicitly "synthesizing" package repos with histories from some kind of a descriptive structure in a place next to the tests should prevent frustrations like this in the future (hopefully).

So far, the testing repo tarball seems to cover these test cases:
- linear history, i.e. no merges
- spec file doesn't exist (first commit only contains a README)
- weird non-UTF8 encodings in the spec file