For three of the tests we use the simpler verify_reply()
API. For the 403 test, we don't need to rely on setUp
any more to simulate everything for us, and we do more
surgical patching.
Move `get_response` inside of `mock_http_conversation`, as it is not
used anywhere else. Also create `assert_called_with_fields`.
`assert_called_with_fields` calls the `assert_called_with` method of a
mock object by using an HTTP request and a list of fields to look for.
This sets us up to validate more aspects of the conversation,
and it also introduces the more rigorously checked
`unique_response` helper.
(This also fixes a minor copy/paste error from a prior commit
that was harmless.)
Note that we now only have one conversation, since the case
of sending to streams has the same mechanics as sending PMs.
We'll eventually want a separate test to drive out differences
in the actual mechanics of the reply.
This method had two pretty easy-to-separate concerns:
* find the fixture data using our directory conventions
* use the fixture data to simulate a real HTTP request
Part of the goal here is to make the extracted functions a
bit easier to use in other TestCase-based classes without
needing to subclass from BotTestCaseBase, which is kind of
complex with its setUp/tearDown.
This program replaces zulip_bot_output.py, which had
gotten a little out of date.
It should be able to simulate a terminal conversation for
all of our bots, including those that use "advanced" features:
third party config files: tested with giphy
message updates: tested with incrementor
storage: tested with virtual_fs and others
Before this change, we were looking for config files in
default locations in source control, which is not a good
place to look for them. Now `run.py` and friends have a
command line argument where users can specify the config
files.
Note that the change to server.py is only a partial fix
to make it so that bots that don't use third party config
files won't crash. That program needs an overhaul, anyway.
This patch is particularly useful in the scenario that your
API key is wrong or out of date, but it's targeted more
generally at any error that `client.get_profile()` reports.
The API has aggressive retry logic for connecting to a
server, which may make sense for situation where you have
connection blips or server restarts.
When you're first connecting to the API, however, connection
failures are almost certainly a sign of misconfiguration, so
now we fail fast.
The bot lib takes advantage of this API change by catching the
ZulipError exception and exiting gracefully.
