You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The complexityReport data is the most interesting part. Mixing in "times depended on" seems a useful way to contextualize a "threat", and coverage can help users better understand the risk.
Maybe just the complexity numbers plus TDO is enough to make decisions
The current coverage mapping is quite limited, requires a specific format, won't work out of the box for almost anyone
The cli makes assumptions that the project has coverage and it has been generated against the current code that has just been scanned, this is not a safe assumption
The cli currently shouts quite loudly when coverage is missing = annoying
It this feature were to be considered valuable, it should probably
Check if the coverage is outdated (e.g. how long ago were these files created?)
Exclude coverage without shouting about it, when it's not available or old
Treat coverage as a nice bonus that users can plug in to enhance the data, rather than something that should be always there
Display the coverage in the CLI output table
Ensure it's included in the main example that contains the full tree
We could also run the coverage step for the user but this could be fraught with bad assumptions so probably isn't worth it.
The text was updated successfully, but these errors were encountered:
A few thoughts
complexityReport
data is the most interesting part. Mixing in "times depended on" seems a useful way to contextualize a "threat", and coverage can help users better understand the risk.It this feature were to be considered valuable, it should probably
We could also run the coverage step for the user but this could be fraught with bad assumptions so probably isn't worth it.
The text was updated successfully, but these errors were encountered: