brainchild0

> Depending in whether the setup should be done once for all tests or per test, this is either `setup_file` territory or #209. That's not the point. The issues are...

> Could you elaborate what exactly do you mean by dependency resolution? Tests generally need resources, such as a connection to a network service, or a file with dummy data....

> How would you distinguish a static vs "dynamic" setup function in bash? "Static" meaning the same execution path of the setup logic for each test in the series. If...

> I have the feeling that this discussion is going in circles and we seem to have trouble communicating effectively with each other. I'll try to summarize one last time...

> Obviously, the formatter can only act in the information that it has available. Therefore, it is constrained by the way TAP delivers these. I'm not sure this response is...

> The internal communication of bats is already a TAP stream plus some additional annotations that get filtered out by the formatters. By design, TAP prints the test outputs after...

I am still working to understand what is happening in the example. Basically, the idea is to avoid some of the limitations in TAP output, bypassing it with a custom...

Do I correctly understand that the structure of the fixture hierarchy is captured only by whatever call sequences are internal to the bodies of the test definitions, and that the...

Well, it definitely adds some flexibility that might be useful as a workaround. It would still add further value if the proposed enhancement would be considered for future development?

Is it at least clear how one might imagine specific fixtures named as dependencies for particular tests (or other fixtures)?