5 ms·
on one hand I suspect too much code has explicit and implicit global state for this technique to be useful; on the other hand using this from the beginning migh
by zem 2y ago
on one hand I suspect too much code has explicit and implicit global state for this technique to be useful; on the other hand using this from the beginning might prevent introducing that sort of global state in the first place.
- James_K 2y agoYou would lose the performance optimisations of a copy, but you can still express tests in this tree fashion with global state. You just need to recurs the tree from the top down and run the entire path up to each node. A simple example: test_fork<A, B, C>(a: A, f: (A) -> B, gs: List<(B) -> C>) -> List<C> { fs.map(g -> g(f(a))) } As you can see, the first step of the test is re-run from scratch every other branch of it.
- AdieuToLogic 2y ago> on one hand I suspect too much code has explicit and implicit global state for this technique to be useful ... Any collaborations having observable side effects such as these are very difficult to prove correct, regardless the test approach employed.
- zem 2y agoyes but resetting the environment before each test is one way to deal with them
- AdieuToLogic 2y ago>>> on one hand I suspect too much code has explicit and implicit global state for this technique to be useful ... >> Any collaborations having observable side effects such as these are very difficult to prove correct, regardless the test approach employed. > yes but resetting the environment before each test is one way to deal with them Not really. Resetting an environment for each test requires distinct tests exist for all anticipated workflow permutations. While this is onerous when the side effects are limited to in-process mutable state (such as global, session, and thread-local data), it is infeasible when global state is a persistent store[0]. 0 - https://en.wikipedia.org/wiki/Data_store https://en.wikipedia.org/wiki/Data_store