cve-bin-tool
cve-bin-tool copied to clipboard
intel
test: PURL generation for language parsers
We're currently in the process of adding PURL generation to our language parsers, but currently aren't using it for anything. Eventually we will as part of the planned gsoc project described in #3771 . But while we're waiting for bigger things, we could definitely stand to have some unit tests!
To avoid wasting time parsing files twice, we may want to add the generate_purl tests into the existingtest_language_package code, and do really basic unit-tests where we throw both valid and invalid vendor, package, version info into generate_purl
I would like to work on this as I'm already working on PURL generation. Would be a good learning experience. @terriko @anthonyharrison
Also, the generate_purl test would be aimed at testing the generate_purl function of the language parsers, or the basic version written in __init__.py?
Would we take normalization into consideration when we are testing the function?
@terriko @anthonyharrison
The goal is always for us to get as close as possible to 100% test coverage, so definitely both. If you've never worked with code coverage tools like codecov, they can help you figure out what parts your tests cover and which parts are not covered.
Note that I don't actually expect us to get to 100% over all of cve-bin-tool because it is asymptotically hard, some of the code has to be tested against real data, and some of the tests would take a long time, so we aim to hover around 80% mostly as a balance of coverage vs practicality. But for something like this where you're literally just making a string and it'll execute in a few microseconds, there's no reason not to test Every Possible Code Path, unless of course upon testing it you realize that a lot of them could be collapsed into a single code path so you don't have to write as many tests. Refactoring is a valid way to improve code coverage too. 📈