morgan/Grinch-AP
1
0
Fork 0
mirror of https://github.com/MarioSpore/Grinch-AP.git synced 2025-10-21 04:01:32 -06:00
Code Issues Packages Projects Releases Wiki Activity

Docs: tests: add naming / file naming conventions (#4982)

Browse Source 
* Docs: tests: add naming / file naming conventions

Deprecates putting stuff into `__init__.py`.
This may be relevant for test discovery in the future.

* Docs: tests: fix class naming

* Docs: tests: update examples

* Punctuation is hard

Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>

* Revert part of one suggestion

The first set of () make the sentence make less sense.

* Docs: tests: clarify that __init__.py may be empty

* Make sentence nicer to read

I simply kept the original wording, but I agree that it reads somewhat odd

Co-authored-by: Ixrec <ericrhitchcock@gmail.com>

---------

Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
Co-authored-by: Ixrec <ericrhitchcock@gmail.com>
This commit is contained in:
black-sliver
2025-05-13 07:49:43 +00:00
committed by GitHub
parent 8340371f9c
commit feaed7ea00
1 changed files with 9 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/tests.md
View File

@@ -11,8 +11,13 @@ found in the [general test directory](/test/general).
## Defining World Tests ## Defining World Tests
In order to run tests from your world, you will need to create a `test` package within your world package. This can be In order to run tests from your world, you will need to create a `test` package within your world package. This can be
done by creating a `test` directory with a file named `__init__.py` inside it inside your world. By convention, a base done by creating a `test` directory inside your world with an (empty) `__init__.py` inside it. By convention, a base
for your world tests can be created in this file that you can then import into other modules. for your world tests can be created in `bases.py` or any file that does not start with `test`, that you can then import
into other modules. All tests should be defined in files named `test_*.py` (all lower case) and be member functions
(named `test_*`) of classes (named `Test*` or `*Test`) that inherit from `unittest.TestCase` or a test base.
Defining anything inside `test/__init__.py` is deprecated. Defining TestBase there was previously the norm; however,
it complicates test discovery because some worlds also put actual tests into `__init__.py`.
### WorldTestBase ### WorldTestBase
@@ -21,7 +26,7 @@ interactions in the world interact as expected, you will want to use the [WorldT
comes with the basics for test setup as well as a few preloaded tests that most worlds might want to check on varying comes with the basics for test setup as well as a few preloaded tests that most worlds might want to check on varying
options combinations. options combinations.
Example `/worlds/<my_game>/test/__init__.py`: Example `/worlds/<my_game>/test/bases.py`:
```python ```python
from test.bases import WorldTestBase from test.bases import WorldTestBase
@@ -49,7 +54,7 @@ with `test_`.
Example `/worlds/<my_game>/test/test_chest_access.py`: Example `/worlds/<my_game>/test/test_chest_access.py`:
```python ```python
from . import MyGameTestBase from .bases import MyGameTestBase
class TestChestAccess(MyGameTestBase): class TestChestAccess(MyGameTestBase):