Integration tests didn't catch non-existent `rates_diff` object

[FM-17]

2021-12-19 23:38:22,967:INFO:poglink.cogs.rates: Cog Ready: Rates
Ignoring exception in on_ready
Traceback (most recent call last):
  File "/home/fm/.pyenv/versions/3.7.0/envs/venv6/lib/python3.7/site-packages/discord/client.py", line 343, in _run_event
    await coro(*args, **kwargs)
  File "/home/fm/.pyenv/versions/3.7.0/envs/venv6/lib/python3.7/site-packages/poglink/cogs/rates.py", line 174, in on_ready
    if rates_diff.items:
AttributeError: 'coroutine' object has no attribute 'items'
/home/fm/.pyenv/versions/3.7.0/envs/venv6/lib/python3.7/site-packages/discord/client.py:350: RuntimeWarning: coroutine 'Rates.compare_posted_rates' was never awaited
  pass

This error was thrown due to the following line not being awaited in rates.py

rates_diff = self.compare_posted_rates(url, output_path)

This issue was resolved. However, the integration tests passed without issue.

Need to investigate why these passed.

[travipross]

I've taken a moment to review closer and I think I realized why this happened, and I now believe this was just an issue of a mistake that lied outside of reasonable test coverage. My reasoning:

• It is unreasonable to test a function that is intended to run continuously via a while True loop. I believe recommended practice (and at least what makes sense to me personally) is to split the logic of the loop out into a helper function and test that helper instead.
• The await was missing on the line where the helper function was being called, not within any of the tested logic. So this is inherently difficult to incorporate into a test.
• The discrepancy is just that the async method (compare_posted_rates) was being called with the necessary await in the associated test, but was missing it in the application code.

Technically the integration test for the cog will never truly be end-to-end as long as it's not calling on_ready() directly, but to do that feels non-trivial/unreasonable because of the while True loop that is required in that method.

I propose we close this issue and just chalk the problem up to being a very narrow edge case that isn't covered by tests and happened to have a syntactic error. The alternative would be to look into methods of testing while True loops which contain async code, but then you'd have to be concerned with the timing of the tests because you'd have to ensure a predictable number of iterations took place asynchronously before making your assertions (because the function isn't stateless, and the number of iterations will change the outcome). That just doesn't sound fun lol

[FM-17]

Agreed.