]> Repositories - hackapet/Adafruit_Blinka.git/blobdiff - examples/index.md
Retired notes directory
[hackapet/Adafruit_Blinka.git] / examples / index.md
diff --git a/examples/index.md b/examples/index.md
new file mode 100644 (file)
index 0000000..b2c1a82
--- /dev/null
@@ -0,0 +1,62 @@
+This repository is structured around integration tests found in the python/testing
+directory. The tests offer a procedural way to assert equivalence between 'native' CircuitPython (CP) behaviour and 
+behaviour of the MicropythonCircuitPython (MCP) layer.
+
+
+In particular, automated introspection of the python runtime combines with interactive prompts
+to configure a scenario for testing (e.g. which platform, which board, what is wired to it) meaning that 
+the same routines can be carried out on Micropython boards, dual boards running either CP or MCP
+or dedicated CP boards. 
+
+From a project-management point of view, tests can provide a strictly-interpreted way to 
+communicate missing features, also providing the implicit means of verifying that intended 
+features for the MCP layer are in fact already served from the CP layer.
+
+# Example
+
+To take a minimal example, the following asserts the default behaviour of the DigitalInOut 
+constructor, checks the behaviour of switch_to_input/output(), configures a pin as a pull-up button, a pull-down button and an LED.
+
+```python
+import testing
+testing.main()
+```
+
+## Comments
+
+There are routines in the top level of the repo like `upload_feather_m0_watch.py` which selectively synchronize files it with the CIRCUITPY or PYBFLASH folder for stm32 and samd21 (with a file-watching behaviour for edits), or which execute a selective ampy upload for CircuitPython/Micropython on esp8266.
+
+Given the limited memory available, on the Feather M0 Express, running the test case requires that 
+the [micropython-lib unittest library](https://github.com/micropython/micropython-lib/blob/master/unittest/unittest.py) 
+is distributed as a compatible Micropython bytecode .mpy file 
+pre-compiled under an mpy-cross version from the CircuitPython 2.2.3-tagged repository. Otherwise
+simply loading the unittest module already busts the available memory. 
+
+# Test Suite Structure
+
+The structure of the testing modules is as follows, to permit test suites to be imported selectively
+on different implementations, platforms and boards (see agnostic.py for definitions of these terms)...
+
+* _testing_ - common function definitions for suite-execution
+* _testing.mcp_ - test suite for hardware-agnostic elements of MCP layer (e.g. Enum)
+* _testing.implementation_ - calculates implementation-specific parameters for test fixtures
+* _testing.implementation.all_ - suites expected to run on all platforms
+* _testing.implementation.micropython_ - suites testing MCP-specific classes and behaviours (under the hood of the hardware compatibility layer) and only 
+expected to run on Micropython
+* _testing.implementation.circuitpython - suites testing CircuitPython-specific 
+classes and behaviours, and only expected to run in CircuitPython_
+
+e.g.
+* testing.implementation.all.digitalio - tests against the 
+digitalio module regardless of platform
+* testing.implementation.circuitpython.digitalio - tests of digitalio against a 
+native circuitpython host
+* testing.implementation.micropython.digitalio - tests of digitalio against the MCP
+compatibility layer
+
+
+# Next Steps 
+
+To be able to run a substantial series of testing modules, a dedicated 
+feather m0 express firmware image should be prepared with [frozen modules](https://learn.adafruit.com/micropython-for-samd21/frozen-modules) which 
+minimises overhead by holding test definitions in flash instead of RAM.