- The `BotHandler` Protocol is a mypy Protocol
s.t. all BotHandlers can use it as a default type.
- Fix ExternalBotHandler and StubBotHandler to
follow `BotHandler` Protocol
Fixes part of #639
It adds a react() function that allows a bot to react to a message in lib.py.
It adds an example of the use of react() function and its test.
The changes are in the following files:
- lib.py
- helloworld.py
- tests/test_lib.py
- test_lib.py
Previously the test-bots script filtered out base-class tests from
BotTestCase. With this change, BotTestCase continues to inherit from
unittest.TestCase, but the default test_* methods previously in this
class are now in a new DefaultTests class, which does not. Instead, each
bot needs to inherit from BotTestCase and DefaultTests *explicitly*.
This avoids the need to filter out the base-class tests, which
simplifies the test-bots script, and may ease any migration to eg.
pytest.
The DefaultTests class does require some non-implemented methods which
BotTestCase provides.
This improves the ability of a bot to specify how to mention it,
which varies at run-time depending upon the identity used to run it;
this is commonly used in many bot help commands.
This method allows bots to validate their config info
in a standardized way. Adding the method to a bot is
optional, but recommended for bots with config options
that can be invalid, like api keys. The giphy bot serves
as an example.
The primary reason behind this is to allow the zulip
backend to validate config data for embedded bots. The
backend does not have a permanent bot class instance, so
validate_config() must be a static method.
bot_handler.quit() should be used whenever a bot
wishes to terminate. This allows a flexible reaction
suited to the bot's environment: For external bots,
sys.exit() will be called, whereas for embedded bots,
different code can be executed.
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.
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
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.)
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.
