-
Notifications
You must be signed in to change notification settings - Fork 89
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
Increase unit test coverage to 100% #652
Comments
I'm surprised there was a 100% coverage requirement, this is not something we have in the other bosh related repo's. Could you make a PR to remove the line about the 100% from: https://github.com/cloudfoundry/bosh-azure-cpi-release/tree/master/.github? |
See: cloudfoundry#652 (comment) Note: The new template content is similar to corresponding content within the Vsphere CPI's PR template.
Done. See #654. |
These Pending specs were removed at the request of @beyhan. See also: - cloudfoundry#651 (review) - cloudfoundry#652
…_config_spec.rb. Note: These new specs cover some previously-uncovered lines of existing code. Related to commit #c7c47dddd64e515a1dbb2d7971b91d676110f216.
…g_spec.rb. Note: These new specs cover some previously-uncovered lines of existing code. Related to commit #c7c47dddd64e515a1dbb2d7971b91d676110f216.
Is your feature request related to a problem? Please describe.
The PR template states that 100% code coverage is a requirement for every PR, but coverage seems to have gone down to ~99% quite a while ago.
Describe the solution you'd like
Ideally, more specs should be added to cover all currently-uncovered lines of code and return the unit test suite to 100% of lines covered.
Note: PR #651 added 9 Pending (unimplemented) unit specs (plus corresponding
TODO: coverage:
comments) to make it clearer which specs should be added to achieve this goal.Describe alternatives you've considered
Alternatively, the PR template message could be updated so that 100% is no longer a stated requirement for PR submission/approval.
Additional context
Note: The existing unit tests/specs would likely continue to pass even if any "effectively-uncovered code" sections (either those referenced above and/or others) are and/or become broken, and therefore the unit tests are likely to fail to detect a variety of potential functional regressions/defects affecting such code.
The text was updated successfully, but these errors were encountered: