This should make TestCommandScriptImmediateOutput more consistent
with the rest of the test suite.
Details
- Reviewers
zturner granata.enrico
Diff Detail
Event Timeline
You can probably remove the expected failure windows if this is no longer
going to be a pexpect test.
Why are we trying to do this in the first place?
The entire purpose of this test is to verify the immediate output to the console.
If you want to test the output to a file instead, make a separate test case, that would be fine. But I'd rather much leave this test alone.
As of r264351, this test already writes to both the console and to files (since the file writing is testing the same python file io bugs tested by the console writing). I can make another patch to split it out if that's preferable.
However, this patch is intended to move the test off of PExpect, because I noticed that sendline() has some issues when running with older versions of lldb (like 3.8, for example), regardless of whether we're testing files or the console.
My personal preference would be to split up the test cases. I'd really like to keep testing the immediate output to console scenario since it is interesting for - e.g. - kernel debugging at Apple.
Would it be acceptable to split it into two test methods inside the same test case? Both are testing writing immediate output from a command script, just one is immediate output to the console and the other is immediate output to a file.
Sure, that works. My only concern is that I'd like to keep the current PExpect-let's test writing to the console and see what happens behavior
Whatever you need to do to split the test is fine by me
Oh I see. I don't think the file-writing is going to work in the PExpect mode (for some reason, it looks like the sendline calls aren't always being received/processed correctly by lldb, while runCmd works fine), so it's probably better to split out into a different test case then.
I don't think we are seeing this behavior on OS X (the failure to process sendline() calls) - but Todd Fiala might know more about that since he keeps a careful eye over our bots.
Longer term, it would be interesting to find out *why* those issues are happening. For now, a test case split sounds reasonable.
I do observe the sendline() behavior on OSX, but only when I cherry-pick these bug-fixes onto the 3.8 branch. It seems to work fine on master.