| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| | | | | | |
|
| | | |_|/
| |/| | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
One of the test_time methods did not actually assert the exception message it was trying to detect as the assertion statement was contained within the context manager handling the exception. I've moved it out of the context so it actually runs.
I've also added a few `praga: no cover` comments for parts that were artifically lowering coverage of the test suite.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Python 3.8 introduced an `unittest.mock.AsyncMock` class that can be used to mock coroutines and other types of asynchronous operations like async iterators and async context managers. As we were using our custom, but limited, AsyncMock, I have replaced our mock with unittest's AsyncMock.
Since Python 3.8 also introduces a different way of automatically detecting which attributes should be mocked with an AsyncMock, I've changed our CustomMockMixin to use this new method as well. Together with a couple other small changes, this means that our Custom Mocks now use a lazy method of detecting coroutine attributes, which significantly speeds up the test suite.
|
| | | | |
| | | |
| | | |
| | | | |
I forgot to remove one pytest test file during the migration from pytest to unittest. Since we have sinced added a unittest version of the same file, I've now removed the lingering pytest file.
|
| | | | |
| | | |
| | | |
| | | | |
Since we upgraded to Python 3.8, we can now use the new IsolatedAsyncioTestCase test class to use coroutine-based test methods instead of our own, custom async_test decorator. I have changed the base class for all of our test classes that use coroutine-based test methods and removed the now obsolete decorator from our helpers.
|
| | |/ /
|/| |
| | |
| | |
| | |
| | | |
We used inheritence to add additional logging assertion methods to unittest's TestCase class. However, with the introduction of the new IsolatedAsyncioTestCase this extension strategy means we'd have to create multiple child classes to be able to use the extended functionality in all of the TestCase variants.
Since that leads to undesirable code reuse and an inheritance relationship is not at all needed, I've switched to a mixin-composition based approach that allows the user to extend the functionality of any TestCase variant with a mixin where needed.
|
| |\ \ \ |
|
| | |\ \ \ |
|
| | | |/ / |
|
| | | | | |
|
| | | | | |
|
| | |\| | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This will prevent child classes to be instantiated unless they implement
all abstract methods, leading to a more descriptive error message.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will serve as an ABC for tests for individual rules.
The base class provides runners for allowed and disallowed
cases, and the children classes then only provide the cases
and implementations of helper methods specific to each rule.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
The name msg is less descriptive and creates a needless name conflict in local gen exp.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The rule was incorrectly printing out the maximum amount of allowed attachments
instead of the configured interval. This commit also adjusts the rule's unit
test case.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/| |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
(hopefully).
|
| | |/
|/| |
|
| | |
| |
| | |
Move the link to Ned Batchelder’s talk and link the note to the section
|
| |/ |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Similar to `format_infraction_with_duration` ( if not outright copying it ), added 3 tests for `until_expiration`:
- None `expiry`.
- Custom `max_units`.
- Normal use cases.
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
context manager.
|
| | | |
| | |
| | |
| | | |
test case tests.
|
| | | |
| | |
| | |
| | | |
`test_parse_rfc1123`, fixed typo.
|
| | | |
| | |
| | |
| | | |
independent tests.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| | |
Co-Authored-By: Mark <[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`.
|