Skip to content

Add test guidelines #1129

Description

@lukpueh

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!

Activity

  1. added
    discussionDiscussions related to the design, implementation and operation of the project
    on Sep 10, 2020
  2. changed the title [-]Discuss/Add test guidelines[/-] [+]Add test guidelines[/+] on Sep 10, 2020
  3. added
    documentationDocumentation of the project as well as procedural documentation
    on Sep 10, 2020
  4. lukpueh commented on Sep 10, 2020

    @lukpueh
    MemberAuthor

    @jku kindly provided some insights about test metadata in #870 (comment). They might be a good fit for a test guideline.

  5. trishankatdatadog commented on Sep 10, 2020

    @trishankatdatadog
    Contributor

    I personally find CodeCov to be next to useless

  6. MVrachev commented on Nov 13, 2020

    @MVrachev
    Collaborator

    I will add to this issue to remove the requirement (which is seen in test_updater.py) to use this format for test names:
    "test_" + <id of the test in the file> + "_" + <function_to_be_tested_" .

    Probably, they have decided to use that pattern before to have an alphabetical order of the tests in the order they are in updater.py, but we have multiple tests with the name test_2_*, test_1_* and test_X_* as a whole.

    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...

  7. jku commented on Nov 13, 2020

    @jku
    Member

    the test_1_... style is typically used to achieve a specific order for the tests to run in (you might want that because the tests are borken so they require state from previous tests, but more often just because you want to bail out early if some fast preliminary tests fail and not spend time in slower more complex tests). This ordering actually fails in tuf because unittest of course sorts alphabetically: "test_10_" is run before "test_1_".

    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_...").

  8. MVrachev commented on Nov 13, 2020

    @MVrachev
    Collaborator

    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.
    We don't need to execute our tests in a particular order.

  9. MVrachev commented on Nov 14, 2020

    @MVrachev
    Collaborator

    If the others agree with this, I can push a pr to rename the tests?

  10. added a commit that references this issue on Dec 1, 2020
  11. lukpueh commented on Dec 1, 2020

    @lukpueh
    MemberAuthor

    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.

  12. added a commit that references this issue on Dec 1, 2020
  13. MVrachev commented on Nov 10, 2021

    @MVrachev
    Collaborator

    We should document that we use with self.assertRaises instead of self.assertRaises as decided in #1660.

  14. lukpueh commented on Apr 1, 2025

    @lukpueh
    MemberAuthor

    The code base is a lot more stable, compared to the time of creating this issue. This means:

    • huge amounts of new test code are not expected
    • existing test code can be used as guideline
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionDiscussions related to the design, implementation and operation of the projectdocumentationDocumentation of the project as well as procedural documentation

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions