If the intent is to test with multiple versions of rpm database, I’d love to make it more clear how to add them.
But I’m also not sure I understand
, it looks like it’s operating on the rpm db, vs something integration style of calling query against the table
01/28/2021, 6:39 PM
Can you guys leave notes on the PR? The intent of the PR is to test that the RPM APIs work. For context some assumptions about the API change in the newer librpm versions and our current integration tests do not catch this since they only run on debian machines. Adding a RPM-based integration test machine is also a good idea but IMO a unit-style test that runs everywhere is the best.
And yeap, the code is written to support more tests easily. Right now we only support 1 type of RPM database. When I bump the librpm version we will have the ability to support a few more, and I will add more tests. 🙂
It will look like this:
• Add single test for the single type of RPM db
• Bump librpm and continue to support a single type of db
• Change a config option in how we build librpm to support sqlite and dbn types and add tests for these
01/28/2021, 6:51 PM
Do you think it makes sense to test the API (as you’re doing) vs querying a test distributed database?