Merge remote-tracking branch 'origin/improved-ci'

# Conflicts:
#	.github/workflows/python-test.yml

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,84 @@
+<!--
+
+Before you open this PR:
+
+1. Have you tested?
+2. Have you read the contributing guidelines?
+3. Do you have a helpful description of your changes?
+4. **Should it be a draft for now?**
+5. Have you got a demonstration of changes, if applicable?
+
+
+It is encouraged to use GPG or SSH signing for your commits.
+If your PR has many commits, it will likely be squash-merged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+-->
+# Description
+
+<!-- Write a brief description about what this PR aims to achieve here -->
+
+## Type of change
+
+<!-- This is simply for triage purposes. You can select multiple. -->
+<!-- Feel free to check only the boxes you need and remove the other ones, or keep them. -->
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] Non-breaking new feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+- [ ] Documentation update
+
+<!-- Guide to "what is my PR???"
+
+- A bug fix is just that - a fix to an existing bug. Does not introduce any new functionality beyond
+fixing the bug.
+
+- Non breaking new feature - a new feature that is entirely backwards compatible with the previous
+release
+
+- Breaking change - a new feature, or change to an existing one that is core to the library/heavily
+used, and is not backwards compatible with the previous release
+Such changes could be changes to logging in, or sending messages, or parsing events.
+Generally, signature changes of the client are regarded as "breaking", unless they're
+underscored functions.
+
+- Documentation update - changes to the documentation, README, or other documentation files.
+-->
+
+## Checklist
+
+<!-- This is just to make sure you've actually read stuff -->
+
+- [ ] I acknowledge that incorrectly filling in this template will result in my PR being closed.
+- [ ] I have read and understood the [contributing guidelines](https://github.com/nexy7574/nio-bot/blob/master/CONTRIBUTING.md).
+- [ ] I have ensured that my code follows this project's formatting.
+<!-- tip: `ruff format && ruff check --fix`. CI will scream at you if you don't. -->
+- [ ] I have unit tested my code.
+  - [ ] I have added additional tests to the suite to cover my changes, where necessary.
+  <!-- if you're not making any changes that change behaviour, like docs changes, check this anyway -->
+  - [ ] I have tested my changes locally in a live environment.
+  <!-- ^ This one is optional but highly appreciated and encouraged. -->
+
+
+## Additional context/demonstration
+
+<!-- If you've got anything to show off, put it here! -->

.github/workflows/python-test.yml

@@ -31,4 +31,4 @@ jobs:
           ruff check --show-fixes
       - name: Run tests
         run: |
-          NIOBOT_DEPRECATION_ERROR=1 pytest
+          NIOBOT_DEPRECATION_ERROR=1 pytest --cov=src/niobot src/tests/

CONTRIBUTING.md

@@ -15,7 +15,7 @@ If you're unsure whether a feature is in scope, feel free to open an issue and a
 You should consider the following questions too:
 
 <details>
-<summary>A list of questions to ask yourself before contributing new features.</summary>
+<summary>A list of questions to ask yourself before contributing new features.</summary>.
 
 ### 1. Is this feature useful for more than me?
 
@@ -41,6 +41,50 @@ whether it should be implemented. If you're unsure, feel free to ask.
 Remember - technical debt exists. If you add something to nio-bot, it has to be maintained. If you add something
 that is too complicated, it may be difficult to maintain, and may be removed in the future.
 
+## Contributing - issues
+
+Opening great issues is akin to creating pull requests.
+The best things to include in an issue are:
+
+* A clear yet consise title
+* A clear description
+* Steps to reproduce (if applicable)
+* Expected behaviour
+* Actual behaviour
+* Any other relevant information
+* Screenshots (if applicable)
+* Minimal code examples (if applicable)
+* Any (cleaned & expunged) logs (if applicable. Linking to gists is preferred for large logs.)
+
+If you're not sure if you can submit a helpful issue, please contact someone in the Matrix room for help.
+You might find that you don't even need to open an issue!
+
+## Contributing - pull requests
+
+Generally, pull requests are amazing. But they can only be amazing if your code is just as amazing.
+
+When opening a PR, you should make sure that your code is:
+
+* Formatted
+* Documented
+* Tested
+* Relevant
+
+For formatting (below, by the way) - CI will mark your PR as failed if it is not formatted correctly.
+Always format your code before committing.
+
+For documentation, make sure that your code is documented. This includes docstrings, comments, and any other
+documentation that is relevant to your code.
+
+For testing, you need to make sure that your code is tested.
+NioBot was lacking CI before v1.2's release, but we are now making an effort to improve our CI coverage
+to catch bugs before they make it to the remote.
+
+If you're adding new functionality, please add **5 unit tests** for it.
+If you're fixing a bug, update any relevant tests, and preferrably add a new test or two if possible.
+
+For relevancy, see above.
+
 ## Code style
 
 NioBot now makes use of `ruff` for code formatting, and this is automatically enforced by the CI.
@@ -81,6 +125,8 @@ This means, when you're contributing, you should make sure you don't use any bra
 that a language feature you have is available two versions ago. For example, using `typing.Union` instead of
 the ` | ` union type that was introduced in python 3.10.
 
+> Pro top: Spin up a virtual environment with the lowest supported version, and run pytest in it.
+
 There is no guaranteed support for newer than specified python versions. This includes alpha, beta and
 release candidates.
 Furthermore, in the interest of backward compatibility, it may take a while until nio-bot supports the latest

pyproject.toml

@@ -61,6 +61,7 @@ dev = [
     'pytest',
     'pytest-asyncio',
     'pytest-benchmark',
+    'pytest-cov',
     'pytest-dependency',
     'ruff~=0.9',
     'mike',

src/tests/test_utils_string_view.py

@@ -0,0 +1,23 @@
+import pytest
+
+from niobot.utils.string_view import ArgumentView
+
+STRINGS = [
+    ["hello world", ["hello", "world"]],
+    ["hello 'world'", ["hello", "world"]],
+    ["'hello world'", ["hello world"]],
+    ["hello 'world' 'two'", ["hello", "world", "two"]],
+    ["hello 'world two'", ["hello", "world two"]],
+    ["hello 'world two' three", ["hello", "world two", "three"]],
+    ["\"hello 'world'\"", ["hello 'world'"]],
+    ["""Hello "'`world`'"!""", ["Hello", "'`world`'", "!"]],
+    ['''"""hello world"""''', ["hello world"]],
+    ["""'''hello world''""", ["hello world"]],
+]
+
+
+@pytest.mark.parametrize("string, expected", STRINGS)
+def test_string_view(string, expected):
+    sv = ArgumentView(string)
+    sv.parse_arguments()
+    assert sv.arguments == expected