Details
- Reviewers
douardda ardumont - Group Reviewers
Reviewers - Commits
- rDCIDX2c38d38518c4: Make xml_document_strategy generate elements 'repositories' and 'licenses'.
rDCIDXbc6e4b738eeb: Add test for tree_to_xml.
rDCIDX8be3677a9b06: Make tests generate pom.xml files themselves instead of using xmltodict.unparse.
Diff Detail
- Repository
- rDCIDX Metadata indexer
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Build is green
See https://jenkins.softwareheritage.org/job/DCIDX/job/tox/396/ for more details.
Build is green
See https://jenkins.softwareheritage.org/job/DCIDX/job/tox/397/ for more details.
Please give a bit of context in your commit messages (in git). Like these 2 commits are dealing with tests for example. And 'More keys' is not a good commit message. Like 'fix a bug' is not a valid commit message, generally speaking.
Reword commits:
- Make tests generate pom.xml files themselves instead of using xmltodict.unparse.
- Make xml_document_strategy generate elements 'repositories' and 'licenses'.
Build is green
See https://jenkins.softwareheritage.org/job/DCIDX/job/tox/408/ for more details.
Please give a bit of context in your commit messages (in git). Like these 2 commits are dealing with tests for example. And 'More keys' is not a good commit message. Like 'fix a bug' is not a valid commit message, generally speaking.
Right, we have this documentation about it [1]
It'd be good to have tests around the xml_document_strategy since it's used for tests though.
for maintenance purposes, to make sure we can distinguish between corner cases in tests and ones in production code...
It'd be good to have tests around the xml_document_strategy since it's used for tests though.
How would you do that?
for maintenance purposes, to make sure we can distinguish between corner cases in tests and ones in production code...
What do you mean?
How would you do that?
test around the xml_document_strategy as usual (as many as the inlining of your branching conditions).
There is nothing specific about hypothesis on that function, so it's testable.
What do you mean?
If you have bugs in the current xml strategy used in tests, and the tests does strange things, we can't know what's wrong.
It could be the tests or the production code.
With tests on the strategy implementation, if something is off in the tests (due to modification in the code), we can more safely assume that it's the production code that is bugged and not the utilities around the tests.
Build is green
See https://jenkins.softwareheritage.org/job/DCIDX/job/tox/413/ for more details.
Build is green
See https://jenkins.softwareheritage.org/job/DCIDX/job/tox/538/ for more details.