-
Notifications
You must be signed in to change notification settings - Fork 276
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
Tests refactored code: reorganize testing in test_api #1414
Comments
Yes, agreed on this. I'm not sure new directories are needed (especially if you're just splitting one file into two) but I can live with it. The alternative to splitting into two files (serialization and everything else) is splitting by class: I think that would be worth considering as it seems logical and easy to learn: if I want to look at Key tests I look in |
Splitting |
Yes, the test data definition/generation is an issue: something I'd consider is defining only the data for the "class under test" explicitly and generating test data for any child objects (because they have their own tests and this might allow defining the test data in reasonable space) So something like def child() -> str
# return a valid serialized ChildObject
return metadata.ChildObject(1,2,3).to_string()
valid_parent_instances={
"empty foo list": f"{'foo':[], 'child_object': {child()}}"
"non-empty foo list": f"{'foo':['item'], 'child_object': {child()}}"
"no child": f"{'foo':['item'], 'child_object': None}"
} there is no to_string() currently but you get the idea: we're not trying to test ChildObject validity here but just create a valid one so we can test the parent ... It's totally possible that this does not scale to the complex objects we have: I'm just writing down things I'd test. |
I am not sure if there is a point in separating |
I think the original proposition to split |
Description of issue or feature request:
Currently, there are too many things tested in
tuf/test_apy.py
including:There are multiple occurrences wherein a single test function we have the first two tested
and additional specific testing added.
I propose to:
test_refactor
test_api
into multiple logical test modules.For example:
test_serialization_deserialization
(I can't think of an alternative name...) andtest_metadata_api
(which will contain only API specific to the metadata classes without (de)serialization tests),tests/aggregate_tests.py
.The reason why I propose splitting
test_api
is that it's bloated and hard to navigate through.Additionally, I think that a separate folder for the refactored code will be useful long term considering we are going to add more and more refactored code that should be tested.
Then, one day when we fully replace the old code with the refactored code we can just remove all of the old tests and move the
content of this new folder into the
tests
folder.The text was updated successfully, but these errors were encountered: