Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing strategy #9

Open
enkore opened this issue Dec 22, 2016 · 2 comments
Open

Testing strategy #9

enkore opened this issue Dec 22, 2016 · 2 comments
Milestone

Comments

@enkore
Copy link
Contributor

enkore commented Dec 22, 2016

Unit testing doesn't really cut it here, we'll need small (, but realistic) test cases with actual backups made with the original software that the importer should handle.

Ideas so far

  • Just commit that stuff
  • Add a .tar or similar (why not a Borg repo? Would allow to deduplicate the test cases! ;)
    • Aaand append-only makes it not-overly-terrible for version control.
    • Actually doesn't sound like such a bad idea.
@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented Dec 22, 2016

Well, I shortly also thought about using a borg repo, but tar is just one file and I do not expect huge amount of data in there anyway. Also, it does not in any way depend on the borg version or need repo updates or ...

@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented Dec 22, 2016

Alternatively, we could also use the backup software to dynamically create the test input data at testing time from some generic source files (which we keep in the repo / we have in a .tar).

But that would need us having rsnapshot, rsync, ... installed at test time. We will need that anyway though for any backup software not using a 1:1 copy of the sourcefiles (like rsync does).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants