-
Notifications
You must be signed in to change notification settings - Fork 78
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
feat: create async interface #61
Conversation
Note: tests relying on Collection will fail in this commit
Adding |
Base class refactor now includes #81, which utilizes multiple inheritance to refactor |
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.
Is there a plan to add integration tests in a later PR? There is a lot of mocking going on here and much of it seems to be a little closer to the high level API than I'd expect (but perhaps is necessary due to the way the existing API is implemented).
await transaction._begin() | ||
|
||
err_msg = _CANT_BEGIN.format(transaction._id) | ||
self.assertEqual(exc_info.exception.args, (err_msg,)) |
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 feels like a hollow assertion since we're constructing the expected result in the exact same why the internal code is. It may be better to actually write out the expected message to verify the internal creation of it does what is desired.
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.
That's a good point. If the construction of the error message was marginally more complex I would agree with you hands down, but I feel as though this is acceptable as it is very close to comparing a defined constant string. @crwilcox do you have any strong opinions about this?
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.
A lot of the exception checking is fragile. We already encountered an issue with this in the microgen conversion. Basically we can use the assertRaisesRegex
instead but it isn't much better. We could mock the var so we could see it was called in the impl properly? But again not sure it is better?
TL;DR - ack
@BenWhitehead my thought is to leave system tests until the async microgen client is integrated, as that way we can test for async functionality. As is all of the classes are stubbed out for async, but the actual networked calls are still blocking. What are your thoughts about doing this? Also, just to note, most of the current async unit tests are ported from the sync test cases. In that regard, your comments are applicable to both of them. Would it make sense to fix both the async and sync unit tests in this PR, or should I make a new PR to do that? |
Possibly worth noting. This PR does not contain integration of async generated bits. While the surface is async, the underlying code isn't yet. |
Sounds good, apologies for not understanding the async integration with generated client hasn't already taken place. I think it's fine to leave adding integration tests until that time. Regarding changing both the async and sync unit tests I don't think that is probably necessary as long as there are integration tests that will come. The thing that stood out to me is that there weren't integration tests added in this PR. |
Sorry I wasn't very clear about integration of async, but the changes to the async and sync tests I was referring to was with regards to the fixes you suggested for the async unit tests. Would it be best to integrate these changes into this PR (like I did with the fixing assert syntax), or bundle them in another PR? |
Up to you, either is fine with me. |
It seems any issues are either tracked in issues, or have been addressed. I think this is good to merge. |
Add async interface and testers.