| Commit message (Collapse) | Author | Lines |
|---|
|
* Add a hidden_channels parameter to in_channel decorator to hide
channels from the InChannelCheckFailure error message.
|
|
|
|
https://github.com/python-discord/bot/pull/621
I've changed to unit tests according to the comments made on the
issue. Most changes are straightforward enough, but, for context,
see the PR linked above.
|
|
I moved the check that tests if a payload contains a duck emoji to a
separate method. This makes it easier to test this part of the code
as a separate unit than when it's contained in the larger event
listener.
In addition, I kaizened the name `relay_message_to_duckpond` to the
less verbose `relay_message`; that's already clear enough.
|
|
block and implement the changes requested by Ava
|
|
|
|
|
|
|
|
(like the codeblock reminder) & improve code a slight bit
|
|
|
|
Co-Authored-By: Mark <[email protected]>
|
|
`content_before` and `content_after`
|
|
|
|
Co-authored-by: scargly <[email protected]>
|
|
|
|
This commit adds unit tests that provide a full branch coverage of
the `bot.cogs.duck_pond` file.
|
|
I have added a mock type to mock `discord.Webhook` instances. Note
that the current type is specifically meant to mock webhooks that
use an AsyncAdaptor and therefore has AsyncMock/coroutine mocks for
the "maybe-coroutine" methods specified in the `discord.py` docs.
|
|
The new AsyncIteratorMock no longer needs an additional method to be
used with a Mock object.
|
|
I have added a special mock that follows the specifications of a
`discord.User` instance. This is useful, since `Users` have less
attributes available than `discord.Members`. Since this difference
in availability of information can be important, we should not use
a `MockMember` to mock a `discord.user`.
|
|
The AsyncIteratorMock included in Python 3.8 will work similarly to
the mocks of callabes. This means that it allows you to set the items
it will yield using the `return_value` attribute. It will also have
support for the common Mock-specific assertions.
This commit introduces some backports of those features in a slightly
simplified way to make the transition to Python 3.8 easier in the
future.
|
|
The `DuckPond.on_raw_message_add` event listener makes an API call to
fetch the message the reaction was added to. However, we don't need
to fetch the message if the reaction that was added is not relevant
to the duck pond. To prevent such unnecessary API calls, I have moved
the code that checks for the relevance of the reaction event to
before the code that fetches the message.
|
|
To allow for separate testing of the code that relays messages to the
duck pond, I have moved this part of the code from the event listener
to a separate method. The overall logic has remained unchanged.
In addition, I've kaizened to things:
- Removed unnecessary f-string without interpolation;
- Removed double negative (not item not in list)
|
|
Previously, the presence of any green checkmark as a reaction would
prevent a message from being relayed to the duck pond, regardless of
the actor of that reaction. Since we only want to check if the bot
has already processed this message, we should check for a checkmark
added by the bot.
This commit adds such a user check.
|
|
As stated from the start, our intention is to add custom mock types
as we need them for testing. While writing tests for DuckPond, I
noticed that we did not have a mock type for Attachments, so I added
one with this commit.
In addition, I think it's a very sensible for MockMessage to have an
empty list as a default value for the `attachements` attribute. This
is equal to what `discord.Message` returns for a message without
attachments and makes sure that if you don't explicitely add an
attachment to a message, `MockMessage.attachments` tests as falsey.
|
|
By default, a mocked value is considered `truthy` in Python, like all
non-empty/non-zero/non-None values in Python. This means that if an
attribute is not explicitly set on a mock, it will evaluate at as
truthy in a boolean context, since the mock will provide a truthy
mocked value by default.
This is not the best default value for the `bot` attribute of our
MockMember type, since members are rarely bots. It makes much more
intuitive sense to me to consider a member to not be a bot, unless we
explicitly set `bot=True`.
This commit sets that sensible default value that can be overwritten
by passing `bot=False` to the constructor or setting the `object.bot`
attribute to `False` after the creation of the mock.
|
|
|
|
Previously, the coroutine object passed to `MockBot.loop.create_task`
would trigger a `RuntimeWarning` for not being awaited as we do not
actually create a task for it. To prevent these warnings, coroutine
objects passed will now automatically be closed.
|
|
Our custom `discord.py` now follow the specifications of the object
they are mocking more strictly by using the `spec_set` instead of the
`spec` kwarg to initialize the specifications. This means that trying
to set an attribute that does not follow the specifications will now
also result in an `AttributeError`.
To make sure we are not trying to set illegal attributes during the
default initialization of the mock objects, I've changed the way we
handle default values of parameters. This does introduce a breaking
change: Instead of passing a `suffix_id`, the `id` attribute should
now be passed using the exact name. `id`.
This commit also makes sure existing tests follow this change.
|
|
The `name` keyword argument has a special meaning for the default
mockobjects provided by `unittest.mock`. This means that by default,
the common d.py `name` attribute can't be set during initalization of
one of our custom Mock-objects by passing it to the constructor.
Since it's unlikely for us to make use of the special `name` feature
of mocks and more likely to want to set the d.py `name` attribute, I
added special handling of the `name` kwarg.
|
|
Previously, logging messages would output to std.out. when running
individual test files (instead of running the entire suite). To
prevent this, I've added a `for`-loop to `tests.helpers` that sets
the level of all registered loggers to `CRITICAL`.
The reason for adding this to `tests.helpers` is simple: It's the
most common file to be imported in individual tests, increasing the
chance of the code being run for individual test files.
A small downside of this way of handling logging is that when we are
trying to assert logging messages are being emitted, we need to set
the logger explicitly in the `self.assertLogs` context manager. This
is a small downside, though, and probably good practice anyway.
There was one test in `tests.bot.test_api` that did not do this, so
I have changed this to make the test compatible with the new set-up.
|
|
over each word.
|
|
Basically I suck at this and I can't get this return_value thing to work.
I'll have Ves look at it to resolve it.
As of right now, multiple tests are failing.
|
|
|
|
Also gets started setting up for the final tests, which will require
more mockwork.
|
|
|
|
|
|
unfinished markdown is left in
|
|
|
|
|
|
|
|
Co-authored-by: scargly <[email protected]>
|
|
|
|
|
|
|
|
Unindent subsequent lines after check
|
|
[kaizen] limit on_message listener to verification channel
|
|
Co-Authored-By: Kyle Stanley <[email protected]>
|
|
|
|
|
|
|
MarkKoz
Leon Sandøy
Sebastiaan Zeeff
Deniz
scragly
Shirayuki Nekomata
Numerlor
Leon Sandøy
Derek
kwzrd
kwzrd
kosayoda