-
Notifications
You must be signed in to change notification settings - Fork 273
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
Add test guidelines #1129
Comments
@jku kindly provided some insights about test metadata in #870 (comment). They might be a good fit for a test guideline. |
I personally find CodeCov to be next to useless |
I will add to this issue to remove the requirement (which is seen in Probably, they have decided to use that pattern before to have an alphabetical order of the tests in the order they are in It's really annoying when you have to add a single test which is in the middle of the test file sequence how you have to change all test names below yours. Even more annoying is you are unlucky to place your test at the begging of the test sequence... |
the I'd say there's probably no reason to use that numbering for new tests -- and there's no problem in multiple tests having the same number: the point is usually just to define a rough order (so all "test_1_..." get executed before all "test_2_..."). |
Still, I think this is unnecessary and confusing and it's better if it's removed. |
If the others agree with this, I can push a pr to rename the tests? |
We want to keep the style guide as minimal as possible. Recommendations about code testing should go into a separate document (see theupdateframework/python-tuf#1129).
See lukpueh/code-style-guidelines@57ed297 and secure-systems-lab/code-style-guidelines#21 (comment) pp. for basic recommendations that used to be in the code style guide. |
We want to keep the style guide as minimal as possible. Recommendations about code testing should go into a separate document (see theupdateframework/python-tuf#1129).
We should document that we use |
The contribution docs say, new software features or changes must be unit tested, but the current test suite is a mix of unit-, integration-, system-, regression-, etc. tests.
It would be helpful to better structure different types of tests in the test suite, and to add some guidelines for testing.
Personally, I have chosen a pragmatic non-SWE approach, a la
"Tailor your tests towards checking the desired functionality of your code and not the coverage report!
The text was updated successfully, but these errors were encountered: