This adds mypy annotations, and we also make the type
conversions in `handle_message` be a little more clear.
(@showell helped clean up this commit a bit)
The new module mocks out calls to the requests library, which
is used by many of our bots that use third party services.
Mocking of requests.py is mostly orthogonal to our other
testing concerns.
All of the functionality of BotTestCase was either directly
moved to StubBotTestCase or replaced by similar functions,
and all bots have been ported to StubBotTestCase.
Chess Bot is a bot that allows you to play chess against either another
user or the computer. Use `start with other user` or
`start as <color> with computer` to start a game.
In order to play against a computer, `chess.conf` must be set with the
key `stockfish_location` set to the location of the Stockfish program on
this computer.
Use `bot_handler.storage` to preserve game state across messages.
(@showell also did minor work here to have the test use verify_dialog()
and have the bot respond to empty messages)
This is mostly a pure refactoring, but it also ensures
that `initialize` is called in a consistent way by most
of our test helpers. (This didn't cause problems before,
since some bots don't require initialization.)
From @showell:
We had a PR here with lots going on, and the commits weren't
very well organized, and then there were some tricky merge
conflicts from another PR. So I just squashed them all into
one commit.
What this does:
* allow you to configure your followup stream
* provide help in followup stream
* add more testing to followup stream
* add get_response() helper for tests
Fixes#173Fixes#174
We can avoid `Any` annotations for `self`, since it is more
noise than signal and since the type of self is already
implicit from how Python classes work.
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.
