-
Notifications
You must be signed in to change notification settings - Fork 1
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
Issue/14 & issue/15 added tests to the dispatcher service #patch #17
Conversation
@timberhill unfortunately test run fails on Windows, adding the log
|
That might be an environment issue though, looking into it |
|
Ah, noted. Hold on |
One more thing - |
@danyloid yup, just fixed that. Check if that works now |
|
Hm, based on a quick search I was not able to find a generic solution :/ |
That being said, do we actually want dispatcher to connect to Reddit during the test run ? |
So does it not work with the |
Does not seem to. This is what I'm getting
|
How do you normally load the |
I don't 😄 I'm used to use All of the cases above are tooling specific - I haven't been able to find a generic way running a script with Granted - I could just set these in system, instead of attempting to use env file, however that is not a clean way to do it. The question however still stands:
I get that in this case the server behavior is predictable, however I'm not used to have extra dependencies in the test execution as a rule of a thumb + we don't really need to test |
Nevermind the |
In CLI I can also run this:
That is a gooooood question. The issue with the dispatcher is, there isn't much unit testing to do, but there are some options:
Making tests depend on an external service is definitely an antipattern, I do understand that. This is why the comment and submission services are mocked - that was simple. But at the same time it's a simple solution for the problem and we can build on that if needed. I have created separate creds for the CI, so there's at least that extremely small consolation. At the same time, I might be missing something here, so please let me know if I did! |
@timberhill you are correct - I'll give the git shell a try, thanks 😄 Regarding the testing - I'm kind of used to go with option 2. Generally I'm trying to avoid testing 3d parties, unless there is a specific reason not to (e.g. hard to mock). |
It is sort of an e2e test for this one particular service though :D But good point about option2, thank you - will have a look if I can utilise python mock for this easily. |
Yes, I get it, but it can also introduce unnecessary flakiness for test executions. |
@timberhill Git Bash seems to leverage WSL2 now, since I have enabled it.
I'm on 3.10
|
NVM, that is Windows too, I've got confused with the UI |
Ok, so WSL2 is the way to do it.
|
Also good point about the python version! It is set in the dockerfile, but I think I use a different one locally. Will have a look. |
Right & we probably need to specify in the README that the dispatcher service requires Linux to run. |
Should be good for review now. The package that talks to Reddit has been mocked - not sure if this is the best way of doing this, but it seems to work. |
@timberhill looks good overall, but since I am not familiar with Python, I would appreciate a bit more elaborate description outlining the approach😄 |
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.
LGTM, have 2 suggestions though:
1. Mocks do not offer option to validate usage declaratively.
I've noticed you essentially have created mocks manually that match the contract that is used in dispatcher, which does make sense. However it does not give you an option to validate calls to specific components if needed.
Would it make sense to use something like https://docs.python.org/3/library/unittest.mock.html ?
That way you also could validate specific calls and parameters passed in test body, rather than having assertions within mock. E.g. via assert_called_with(3, 4, 5, key='value')
2. Request is not validated
Are you validating that the requests were properly initiated for generated comments / submissions ?
Currently requests are mocked, but let's say the dispatcher gets broken in the futured and some data is skipped for whichever reason - this test would likely still succeed, would it not ?
Nor is the request format validated - hence the tests might not catch unintended change.
Unfortunately I need to do a bit of homework to suggest the changes to the codebase, so I'll go do that :)
Hey, I found this: https://requests-mock.readthedocs.io/en/latest/history.html |
Okay, here we are. I have removed most of the previous manual mock and replaced it with python Mock. The only thing that was giving me trouble was async iteration that I think cannot be reasonably mocked via python AsyncMock class. Therefore I have left the Big changes in this whole pull request:
|
@danyloid please tear this apart :D |
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.
@timberhill looks good to me, thanks for making the changes.
Closes #14, #15