-
Notifications
You must be signed in to change notification settings - Fork 0
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
Initial refactor of SystemRepo & Service unit tests #302 #299
Conversation
abe988e
to
7b6f22a
Compare
7b6f22a
to
28b3440
Compare
|
||
self._created_system = self.system_repository.create(self._system_in, session=self.mock_session) | ||
|
||
def call_create_expecting_error(self, error_type: type): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we maybe abstract testing for errors even further? The same function is there for get, edit, delete. Could save some lines, especially if it is applied across all tests for every entity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do, but I am not sure if its in the spirit of this method https://medium.com/@bas.dijkstra54/making-test-frameworks-readable-the-domain-specific-language-c154c9a9abcb. Abstracting further would effectively mean a single function for each test with a bunch of parameters when really they are supposed to be readable through the function names in logical steps. Where right now each are in the format mock, call, assert.
…stem-repo-unit-tests-#90
class SystemRepoDSL: | ||
"""Base class for SystemRepo unit tests""" | ||
|
||
test_helpers: RepositoryTestHelpers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth replacing RepositoryTestHelpers with a base class that the same methods, it would save adding fixtures in a setup function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, this can be done in a separate PR.
self._expected_system_out = MagicMock() | ||
self.test_helpers.mock_update(self.mock_system_repository, self._expected_system_out) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't necessary - I could equally use self.mock_system_repository.get.return_value in the assert later instead of storing this which would make it a bit shorter, although similar to a lot of things in this test file, right now the service layer doesn't do much, later we may need to mock like this with realistic data if there was processing after it to test. This may also be more readable here.
|
||
assert response.status_code == 409 | ||
assert response.json()["detail"] == "A System with the same name already exists within the same parent System" | ||
class ListDSL(GetBreadcrumbsDSL): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its also worth point out I struggled to come up with a consistent naming system throughout these tests, right now its using _system
or _systems
in the method names to distinguish between these and later ones for items where we may be able to reuse logic but its not clear to me until we get that far so could be a case of renaming these then.
Same for the class and method names - should they be the request type or not? Here I have used the request type for methods (although we could also use create, update etc), but Get and List inside the class names simply because I didn't see the worth in putting System/Systems after each, but again it may be obvious later which is best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like you say, it won't be clear until we get that far.
self.post_system(SYSTEM_POST_DATA_REQUIRED_VALUES_ONLY) | ||
system_id = self.post_system(SYSTEM_POST_DATA_ALL_VALUES_NO_PARENT) | ||
self.patch_system(system_id, {"name": SYSTEM_POST_DATA_REQUIRED_VALUES_ONLY["name"]}) | ||
self.check_patch_system_failed_with_message( | ||
409, "A System with the same name already exists within the parent System" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also worth mentioning things like this I don't think are in the spirit of DSL, as really it would require additional functions with names such as
self.create_system_with_child()
self.move_system_to_previously_created_system()
But I thought that going that far is where the disadvantages of the method start to occur as maintenance becomes more awkward so I thought this could be a decent hybrid instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very good work, thank you! It is so much more readable and I hope that it will be easier to maintain in future.
53bc563
to
03920e1
Compare
[system["id"], system["name"]] | ||
# When the expected trail length is < the number of systems posted, only use the last | ||
for system in self._posted_systems_get_data[ | ||
(len(self._posted_systems_get_data) - expected_trail_length) : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(len(self._posted_systems_get_data) - expected_trail_length) : | |
(len(self._posted_systems_get_data) - expected_trail_length): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is black's formatter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ never seen this before 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah me neither 😄
Description
Initial refactor example for system repo unit tests. Code is not actually much shorter for these tests, but I think it is more readable and hopefully easier to maintain as the core test functionality is in one place (there are also some additional asserts that were missing before).
SystemService are actually slightly longer now & the e2e tests are a bit shorter.
Suggestions welcome.
Testing instructions
Agile board tracking
Closes #302