Have a look at Asset Administration Shells (AAS) -- it is a data exchange format built on top of JSON and XML (and RDF, and OPC UA and Protobuf, etc.).
XBox doesn't work outside & in the class room. Now, I wouldn't advocate for playing computer games outside -- but this might be a nice gimmick for children's birthdays when celebrated in the garden.
A friend of mine uses these games in the classroom as a primary school teacher. Kids here all have a laptop, so when they get nervous, it's a neat way for them to make a break & move a bit. Apparently, this works well for kids with hyperactive tendencies. Kinect would be too complicated in that setting as you need to purchase & maintain 20+ Kinects.
Sorry, I did not express myself clearly. For certain functions you can express all the properties in contracts and have them automatically tested.
For other functions, you write some obvious contracts (so that those are also tested in integration tests or end-to-end tests), but since writing all the contracts would be too tedious or unmaintainable, you test these functions additionally using, say, table-driven tests where you specifically test with data points for which you could not write the preconditions or you check the post-conditions manually given the input data. For example, sometimes is easier to generate the input, manually inspect the results and write the expected results in the test table.
> [...] turn contracts into tests [...]
icontract-hypothesis allows you to ghostwrite Hypothesis strategies which you can further refine yourself.
P.S. I think the important bit is not to be religious about contracts and tests. Sometimes it's easy to write the contracts and have the function automatically tested, sometimes unit tests are clearer.
I tend to limit myself to simple contracts and do table tests for the complex cases to reap the benefits of the both approaches.
In my anecdotal experience, it takes very little time for juniors to pick up adding contracts to their code. You need to grasp implication, equivalence, exclusive or, and get used to declarative code, but then it's easy. (I often compare it to SQL.)
I find contracts personally super useful as I can express a lot of relationships in the code trivially and have them automatically verified. For example, when this input is None, then that output needs to be positive. Or if you dele the item it should not exist in this and that registry, and some related other items should also not exist any more.
My email is in the commits of the repository, feel free to contact me and we can have a chat if you are interested in a larger picture and more details.
Just in case you are looking for an alternative approach: if you write contracts in your code, you might also consider crosshair [1] or icontract-hypothesis [2]. If your function/method does not need any pre-conditions then the the type annotations can be directly used.
You can already do that with a family of predicates if you write preconditions in your Python code (see my previous comment [1]). There is an ongoing discussion how to bring this in into Hypothesis (see the issue [2]).
Use contracts and propery-based testing. See Hypothesis library in Python (and other laguages). I wrote a library for contracts in Python (http://github.com/Parquery/icontract, see its readme for further references to other libraries).
I find the combination between unit tests, component tests and contracts the best. Contracts allow you to test with tons of data you wouldn't have ever generated manually when enabled in component and e2e tests.
The contracts obliviate often the need to write extensive unit tests. As they are part of the interface, we can avoid thus to re-write many unit tests when the interfaces change during a refactoring.
I always wondered where this multiplicative factor of "several times" comes from. In my experience, writing correct software was marginally slower than writing sloppy software as long as most thinking is done with a pen & paper. Would you mind to elaborate a bit more?
At my previous job, we used a python script to rsync files -- very, very simple. I think it would have been much more difficult and error-prone with Dockers.
https://industrialdigitaltwin.org/
(Disclaimer: I work on AAS SDKs https://github.com/aas-core-works.)