python-zulip-api
python-zulip-api copied to clipboard
zulip
[WIP] test-framework: Add support for testing lack of replies from bot.
This commit adds a sample test as well as code to support testing usecases where we want the bot to remain silent.
We don't need this feature as of now, but a similar request in the webhooks testing framework prompted me to test this.
This PR is just for testing and feedback, and shouldn't be merged as of now. If we want to merge, I'll remove the sample test and clear up some mypy annotations.
@aero31aero Sorry this took so long to review. I think some of this is a good thing to add to the test framework, but we do want to think it through a bit more.
We probably want a better example than "helloworld", which should really be "dirt simple." Can you think of a less contrived case when a chat bot should ever be slient? For webhook integrations, it makes a lot of sense to just throw certain responses on the floor, but chat bots will almost always have a logical response to bad input, even if it's just saying "I don't understand this command."
Actually, that person asked whether we have something like this in our testing framework and I either misread or he wasn't clear in whether it was bots or webhooks. So, I thought I'll just do a quick fix here and get it merged for his usecase. After committing it I realized he was talking of the webhooks.
I just left is open and completely WIP for now. Possible usecases:
- Game Handler: Each test case could be like this for ensuring that the bot doesn't reply again and only updates the existing message.
test_silence()
test_message_updated()
- A bot designed for logging messages, perhaps? Say,
@summary-bot We talked about XYZ.and at that time the bot doesn't reply. Actually, I'll flesh out this idea a bit in #integrations.
Heads up @aero31aero, we just merged some commits that conflict with the changes your made in this pull request! You can review this repository's recent commits to see where the conflicts occur. Please rebase your feature branch against the upstream/master branch and resolve your pull request's merge conflicts accordingly.
This sounds like a reasonable feature. But I think the use-cases are probably too trivial. We might need to have some further discussions on this one.
