-
Notifications
You must be signed in to change notification settings - Fork 44
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
Unit test Code coverage #12
Comments
You and your colleague are absolutely right. We are pushing code fresh off the oven and deferring the test coverage until after the MVP release. If you recall, we announced in one of our weekly meetings at the beginning of the MVP release cycle that this release will be a "prototype" release. This will not even be an alpha release. That said, we have already started adding test coverage to the code and we will be addressing other "issues" identified by SonarQube gradually. Thank you for your review and feedback. |
In agile practice, development of a feature includes adequate testing to ensure quality. So I apologize for missing you mentioning this earlier and my not pushing this point before. In agile practice, feature testing should occur in conjunction with development, typically in the same sprint. Many teams explicitly stipulate testing as the acceptance criteria for a particular feature/user story. In fact my colleagues argue that a feature should not be closed out until the test coverage is at a pre-defined threshold. They have also mentioned that viability cannot be validated if it is not tested. |
Closing this for now, as we've gotten to 90%+ coverage on the existing code base. |
As mentioned by #5, it looks the unit tests are only hitting 3.5% of the code by SonarQube's account. Within SonarQube it looks like your thresholds are set to 65%.
A colleague who conducted a manual code review had a similar conclusion.
The text was updated successfully, but these errors were encountered: