| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
| |
It has to account for the addition of groups. It's easiest to compare
the entire string so `finditer` is used to return re.Match objects;
the tuples of `findall` would be cumbersome. Also threw in a change
to use `assertCountEqual` cause the order doesn't really matter.
|
| |
|
|
|
|
|
|
| |
It was broken due to the addition of groups. Rather than returning the
full match, `findall` returns groups if any exist. The test was
comparing a tuple of groups to the token string, which was of course
failing. Now `fullmatch` is used cause it's simpler - just check for
`None` and don't worry about iterating matches to search.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The test now ensures the cog is instantiated and that the instance is
passed as an argument to `add_cog`.
|
| |
|
|
|
|
|
|
| |
* Remove `bot.get_cog` mocks in `setUp`
* Mock the logger cause it's easier to assert logs
* Remove subtests
* Assert helper functions were called
* Create an autospec for ModLog
|
| | |
|
| | |
|
| |
|
|
|
| |
* Rely on default values for the author
* Set the content to a non-empty string
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In practice, this won't ever happen since the regex wouldn't match
strings with missing parts. However, the function does check it so may
as well test it. It's not necessarily bound to always use inputs from
the regex either I suppose.
|
| |
|
|
|
|
|
|
| |
The original approach of messing with the `attribute_name` didn't work
for reasons I won't discuss here (would require knowledge of patcher
internals). The new approach doesn't use patch.multiple but mimics it by
applying multiple patch decorators to the function. As a consequence,
this can no longer be used as a context manager.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It's not possible to test this via asserting the return value of
`on_message` since it never returns anything. Instead, the actual
relevant unit, `find_token_in_message,` should be tested.
|
| |
|
|
|
| |
This gives the caller more flexibility. Sometimes attribute names are
too long or they don't follow a naming scheme accepted by the linter.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This helper reduces redundancy/boilerplate by setting default values.
It also has the consequence of shortening the length of the invocation,
which makes it faster to use and easier to read.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The `in_whitelist` decorator should not fail when a decorated command was called in a DMChannel; it should simply conclude that the user is not allowed to use the command. I've added a test case that uses a DMChannel context with User, not Member, objects.
In addition, I've opted to display a test case description in the `subTest`: Simply printing the actual arguments and context is messy and does not actually show you the information you'd like. This description is enough to figure out which test is failing and what the gist of the test is.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The API of the `in_whitelisted_context` decorator was a bit clunky:
- The long parameter names frequently required multiline decorators
- Despite `#bot-commands` being the defacto default, it needed to be passed
- The name of the function, `in_whitelisted_context` is fairly long in itself
To shorten the call length of the decorator, the parameter names were shortened by dropping the `whitelisted_` prefix. This means that the parameter names are now just `channels`, `categories`, and `roles`. This already means that all current usages of the decorator are reduced to one line.
In addition, `#bot-commands` has now been made the default redirect channel for the decorator. This means that if no `redirect` was passed, users will be redirected to `bot-commands` to use the command. If needed, `None` (or any falsey value) can be passed to disable redirection. Passing another channel id will trigger that channel to be used as the redirection target instead of bot-commands.
Finally, the name of the decorator was shortened to `in_whitelist`, which already communicates what it is supposed to do.
|
| |
|
|
| |
I have added tests for the new `in_whitelisted_context` decorator. They work by calling the decorator with different kwargs to generate a specific predicate callable. That callable is then called to assess if it comes to the right conclusion.
|
| | |
|
| |
|
|
|
|
|
|
| |
The `in_channel` decorator that served as a factory for `in_channel` checks was replaced by the broaded `in_whitelisted_context` decorator. This means that we can now whitelist commands using channel IDs, category IDs, and/or role IDs. The whitelists will be applied in an "OR" fashion, meaning that as soon as some part of the context happens to be whitelisted, the `predicate` check the decorator produces will return `True`.
To reflect that this is now a broader decorator that checks for a whitelisted *context* (as opposed to just whitelisted channels), the exception the predicate raises has been changed to `InWhitelistedContextCheckFailure` to reflect the broader scope of the decorator.
I've updated all the commands that used the previous version, `in_channel`, to use the replacement.
|
| |
|
| |
Replaced `TimeoutError` with `asyncio.TimeoutError`.
|
| |
|
|
|
|
| |
The "unsilence" action of the silence/hush command used `send_messages=True` when unsilencing a hushed channel. This had the side effect of also enabling send messages permissions for those with the Muted rule, as an explicit True permission apparently overwrites an explicit False permission, even if the latter was set for a higher top-role.
The solution is to revert back to the `Inherit` permission by assigning `None`. This is what we normally use when Developers are allowed to send messages to a channel.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
Should return 1st arg (or None) if eval cmd in message, otherwise return
full content.
|
| | | |
|
| | |
| |
| |
| |
| | |
The tasks extensions loop requires an event loop to exist. To work
around this, it's been mocked.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
discord.py yields duplicate Command objects for each alias a command
has, so the duplicates need to be removed on our end.
|
| | |
| |
| |
| |
| | |
* Rename `walk_extensions` to `walk_modules` because some extensions
don't consist of a single module
|
| | |
| |
| |
| | |
Have to check the modules are equal to prevent yielding imported cogs.
|
| | | |
|
| | |
| |
| |
| | |
This will help reduce nesting in the actual test.
|
MarkKoz
Sebastiaan Zeeff
ks129
Sebastiaan Zeeff
Eivind Teig