| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a discussion in the core developers channel, we have decided to
migrate from `pytest` to `unittest` as the testing framework. This
commit sets up the repository to use `unittest` and migrates the
first couple of tests files to the new framework.
What I have done to migrate to `unitest`:
- Removed all `pytest` test files, since they are incompatible.
- Removed `pytest`-related dependencies from the Pipfile.
- Added `coverage.py` to the Pipfile dev-packages and relocked.
- Added convenience scripts to Pipfile for running the test suite.
- Adjust to `azure-pipelines.yml` to use `coverage.py` and `unittest`.
- Migrated four test files from `pytest` to `unittest` format.
In addition, I've added five helper Mock subclasses in `helpers.py`
and created a `TestCase` subclass in `base.py` to add an assertion
that asserts that no log records were logged within the context of
the context manager. Obviously, these new utility functions and
classes are fully tested in their respective `test_` files.
Finally, I've started with an introductory guide for writing tests
for our bot in `README.md`.
|
| |
|
|
|
|
|
| |
As we have decided that the converter should return naive datetime
objects, we should explicitly test that datetime strings with a
timezone offset are still converted to a naive datetime object. I
have done this by adding a `tzinfo is None` assertion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser we use, `dateutil.parsers.isoparse` returns a timezone-
aware or timezone-unaware `datetime` object depending on whether or
not the datetime string included a timezone offset specification.
Since we can't compare tz-aware objects to tz-unaware objects it's
better to make sure our converter is consistent in the type it will
return.
For now, I've chosen to return tz-unaware datetime objects, since
`discord.py` also returns tz-unaware datetime objects when accessing
datetime-related attributes of objects. Since we're likely to compare
"our" datetime objects to discord.py-provided datetime objects, I
think that's the most parsimonious option for now.
Note: It's probably a good idea to open a larger discussion about
using timezone-aware datetime objects throughout the library to
avoid a UTC-time being interpreted as localtime. This will require
a broader discussion than this commit/PR allows, though.
|
| |
|
| |
Co-Authored-By: Mark <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related to https://github.com/python-discord/bot/issues/458
This commit adds a converter that automatically parses ISO-formatted
datetime strings and returns a `datetime.datetime` object. It uses
`dateutil.parser.isoparse` to do the heavy lifting, so it supports
the same formats as this method.
In addition, I have added tests that ensure that it accepts certain
formats and added a description of these 'guaranteed' formats to the
`ISODate.convert` docstring.
This commit should make it easy to implement #485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/python-discord/bot/issues/446
After review feedback and a discussion in the dev-core team, I've
changed a couple of things:
- Allow a space between amount and unit in the duration string;
- Allow a space between different units in the duration string;
- Remove the old ExpirationDate converter completely;
- Remove the dependency `dateparser` from the Pipfile;
- Update tests for the two types of optional spaces;
- Change the test for valid cases to a more readable format;
This PR closes #446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/python-discord/bot/issues/446
The current ExpirationDate converter does not convert duration strings
to `datetime.datetime` objects correctly. To remedy the problem, I've
written a new Duration converter that uses regex matching to extract
the relevant duration units and `dateutil.relativedelta.relativedelta`
to compute a `datetime.datetime` that's the given duration in the
future.
I've left the old `ExpirationDate` converter in place for now, since
the new Duration converter may not be the most optimal method. However,
given the importance of being able to convert durations for moderation
tasks, I think it's better to implement Duration now and rethink the
approach later.
This commit closes #446
|
| |
|
Sebastiaan Zeeff
Johannes Christ