Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
testing: using "go tool test2json dlv test-binary" marks the last test as failed on Mac OS #34286
This is continuation of #23033 which is still actual in go1.13.
To reproduce the issue create
and connect debugger from another console:
In the Delve console type
Test2json produces output:
This happens because on Mac OS Delve runs programs via debugserver and debugserver uses
I understand that this is not a bug in test2json. Test2json assumes the output is produced by the test framework and the test framework always uses
In #23033 there was a question: why one would want to debug a test and also see the its final status. The most relevant use-case I can think of is a modification of a program state during debug session. Let's say I have a complex algorithm test for which started to fail. During a debug session I've found a potential problem. I cannot easily change the sources and rerun a test because the fix is complicated, but I can change the program state at runtime. I want to verify that changing some value in a program produces a desirable effect and test starts to pass. At the moment it is not possible as the test status is always "fail".
Test2json is used to simplify test output parsing, json is easier to parse than the raw output produced by test executable. Test2json output is consumed by an editor and is shown in a dedicated UI where each test has an icon according to its status. It is easier to grasp tests status from such a view than from reading output of all tests. Test2json doesn't change the debugging experience per se, but it is useful to be able both debug a test and see its outcome once debug session is over.
If I understand correctly Delve redirects debugserver output to its stdout without changing anything. @aarzilli could you please confirm?
This thing with tests getting \r\n on macOS came out before and I couldn't figure out where it happens. The way it works is that delve runs the test executable under debugserver and then debugserver sends us the output in a stop packet (it's the 'O' kind). It already contains the \r there so either debugserver is adding it (werid) or possibly the tty layer in the kernel (weirder).