Add testing page and improve merge checklist

Author: ThomasFarstrike

docs/os-development/testing.md

@@ -0,0 +1,63 @@
+By default, the unit tests will run automatically when the [GitHub workflows](https://github.com/MicroPythonOS/MicroPythonOS/tree/main/.github/workflows) are triggered.
+
+But when you're working on a unit test, or investigating a failure, you probably want to run it locally for quick iteration.
+
+The tests are stored in [tests/](https://github.com/MicroPythonOS/MicroPythonOS/tree/main/tests)
+
+Simple (non-graphical) test filenames start with `test_` and ends with `.py`.
+
+Graphical tests start with `test_graphical_` and also end with `.py`.
+
+# On Desktop
+
+The following assumes you have MicroPythonOS running on desktop, meaning this works:
+
+```
+./scripts/run_desktop.sh
+```
+
+Then you can run a specific unit test by providing its file as an argument:
+
+```
+./tests/unittest.sh tests/test_package_manager.py
+```
+
+To run all unit tests, do:
+
+```
+./tests/unittest.sh
+```
+
+This takes some time, during which you'll see the MicroPythonOS window pop up often.
+
+There's also a syntax checker:
+
+```
+./tests/syntax.sh
+```
+
+# On Device
+
+The unit tests can also run on a physical device, like an ESP32 that's connected with a USB cable, which is more representative and can help to test features that are not available on desktop.
+
+This takes quite some time, because it restarts the device before each test, to make sure there's no leftover state from a previous test lingering.
+
+The following assumes you have the MicroPythonOS REPL shell show up when you run mpremote.py, meaning this works:
+
+```
+./lvgl_micropython/lib/micropython/tools/mpremote/mpremote.py ls 
+```
+
+Then you can run a specific unit test by adding the --ondevice option and providing its file as an argument:
+
+```
+./tests/unittest.sh --ondevice tests/test_package_manager.py
+```
+
+To run all unit tests, do:
+
+```
+./tests/unittest.sh --ondevice # this takes a long time
+```
+
+

docs/other/merge-checklist.md

@@ -2,17 +2,17 @@ Before merging a pull request, we should consider the following:
 
 Making sure to update related things:
 
-- has [CHANGELOG.md](https://github.com/MicroPythonOS/MicroPythonOS/blob/main/CHANGELOG.md) been updated?
-- has [MAINTAINERS.md](https://github.com/MicroPythonOS/MicroPythonOS/blob/main/MAINTAINERS.md) been updated?
-- has the app's version number (META-INF/MANIFEST.JSON) been incremented?
-- has the [documentation](https://GitHub.com/MicroPythonOS/docs) been updated?
+- does the "Future release (next version)" section at the top of [CHANGELOG.md](https://github.com/MicroPythonOS/MicroPythonOS/blob/main/CHANGELOG.md) need to be expanded?
+- does an App's version number (META-INF/MANIFEST.JSON) need incrementing? Normally only when you modify an App.
+- does the [documentation](https://GitHub.com/MicroPythonOS/docs) need updating? Usually when you modify or add a Framework, but can also be for other things. Always good!
+- does [MAINTAINERS.md](https://github.com/MicroPythonOS/MicroPythonOS/blob/main/MAINTAINERS.md) need to be updated? Usually only when adding a new board that you'll be maintaining.
 
 Making sure the logic is sound:
 
-- if it changes a setting definition, will old settings be properly migrated to the new setting?
-- has a unit test been added or updated to make catch future regressions?
+- if it changes a Setting's definition, will old settings be properly migrated to the new setting?
+- did you add or expand one or more unit tests to make sure your code works, in all edge cases, and future regressions are caught?
 
 Making sure it's easy to review:
 
-- are whitespace changes done in a separate commit (or ideally, separate pull request) from functional changes?
+- are non-functional changes that result in a big diff done in a separate commit (or ideally, separate pull request) from functional changes?
 

mkdocs.yml

@@ -83,6 +83,7 @@ nav:
       - On MacOS: os-development/macos.md
       - On Windows: os-development/windows.md
       - Installing on ESP32: os-development/installing-on-esp32.md
+      - Testing: os-development/testing.md
       - Emulated ESP32: os-development/emulating-esp32-on-desktop.md
       - Porting Guide: os-development/porting-guide.md
   - Other: