the env system code is unecessarily fiddly. The current env system is
the second env system, so the layer system will be the third
implementation of the env system.
the environment in which we run our tests is a layered environment like
the scope in a programming language, but unlike with nested closures,
tea permits the user to supply match tags to skip what would be stack
frames in a system based on nested closures. It's more easily understood
as being a system of layers, and that we skip non-matching layers.
the env system also had the problem that it was a tree that was
dynamically constructed as a side-effect of the execution tree, but each
chain only needs to read its own ancestry in the environment tree.
Having a single tree poses challenges for parellelizing the execution of
different test chains, so instead, I would rather keep a list of layers
for each chain, instead of keeping a single environment tree that is
shared across all chains in the run. Additionally, the env system was
sparse; tests that save no data put no nodes in the env tree. I would
like to be able to display to users the layers available to their test
in certain error cases so that they can understand why a match may have
failed. Right now, in practice, encountering a match failure in a test
plan is confusing to understand.
I keep writing these one-off when I actually use tea. It seems like it's
worth including. It's especially useful for the root test, where you
don't necessarily want to create a test, but want to create a starting
environment. Exporting a type that always passes is preferrable to
making an explicit environment type, since we can maintain our
guarantees that our environment isn't an invalid value.
adding a nested Go modules file because I don't want to update tea's
go.mod file when the examples are run. I don't want to accidentally
check them in.
the env type represents a test environment. This was added as an
intermediate container that could store the saved fields of tests after
they're run, so that future tests could load them. Previously a test
could only get the attributes of the test that immediately preceded it.
This change allows tests to load attributes further back in the history.
this isn't going to work permanently, if there's a save field in one
test, then an intermediate test without that field, then a load field,
it won't be visible at the end test.
