Have debug() include information about where it came from
Description
Enhance debug() to include information about the spec and test it came from so if a developer has multiple debug() calls in many tests they can remember which values came from where. I would recommend wrapping the value being debugged in a struct with a single key that is the name of the spec/test.
Another option is to not collect it in an array, but dump each dubug bit separately with a header before it.
Yet another option is to include debug info up inside the runner along with the other information for that spec/test. Then it will be inherently clear where it belongs.
Gliffy Diagrams
Activity
Show:
Luis Majano November 8, 2014 at 7:33 PM
This was implemented, but forgot to tag it on my commit. I tagged with a different one. Oops
Brad Wood December 27, 2013 at 9:51 PM
I can't say I understand all the issues regarding asynchronicity and pointers, but it seems like this should be possible. We currently collect information about each test such as pass/fail/skipped, so it seems we should be able to save off other information using a similar means.
Even if it is not easy to display the debug output alongside the corresponding test result in the interface, surely it is at least possible to tag the test that was running when the debug was called so a label can be included down below. There must be a way that each thread knows what tests it is running.
Luis Majano December 13, 2013 at 6:31 PM
Each bundle has it's own debug array. However, you cannot do it by test or by spec as they could run asynchronously. So there is no way to create something beforehand, set it on the test that whenever you call debug() it shoudl go in the test you are executing because pointers won't work due to asynchronous testing.
Therefore, I decided to do it as a single buffer array where things get piled up whether they are sync or async. If you find another way, I am all ears
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Enhance debug() to include information about the spec and test it came from so if a developer has multiple debug() calls in many tests they can remember which values came from where. I would recommend wrapping the value being debugged in a struct with a single key that is the name of the spec/test.
Another option is to not collect it in an array, but dump each dubug bit separately with a header before it.
Yet another option is to include debug info up inside the runner along with the other information for that spec/test. Then it will be inherently clear where it belongs.