Commit Graph

3 Commits

Author SHA1 Message Date
Raphael Isemann
54c2687292 [lldb] Introduce createTestTarget for creating a valid target in API tests
At the moment nearly every test calls something similar to
`self.dbg.CreateTarget(self.getBuildArtifact("a.out"))` and them sometimes
checks if the created target is actually valid with something like
`self.assertTrue(target.IsValid(), "some useless text")`.

Beside being really verbose the error messages generated by this pattern are
always just indicating that the target failed to be created but now why.

This patch introduces a helper function `createTestTarget` to our Test class
that creates the target with the much more verbose `CreateTarget` overload that
gives us back an SBError (with a fancy error). If the target couldn't be created
the function prints out the SBError that LLDB returned and asserts for us. It
also defaults to the "a.out" build artifact path that nearly all tests are using
to avoid to hardcode "a.out" in every test.

I converted a bunch of tests to the new function but I'll do the rest of the
test suite as follow ups.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D102771
2021-05-24 16:18:44 +02:00
Dave Lee
010d7a388b [lldb/test] Catch invalid calls to expect()
Add preconditions to `TestBase.expect()` that catch semantically invalid calls
that happen to succeed anyway. This also fixes the broken callsites caught by
these checks.

This prevents the following incorrect calls:

1. `self.expect("lldb command", "some substr")`
2. `self.expect("lldb command", "assert message", "some substr")`

Differential Revision: https://reviews.llvm.org/D88792
2020-10-05 12:41:52 -07:00
David Spickett
9f18f3c858 [lldb] Improve test failure reporting for expect()
This updates the errors reported by expect()
to something like:

```
Ran command:
"help"

Got output:
Debugger commands:
<...>

Expecting start string: "Debugger commands:" (was found)
Expecting end string: "foo" (was not found)
```
(see added tests for more examples)

This shows the user exactly what was run,
what checks passed and which failed. Along with
whether that check was supposed to pass.
(including what regex patterns matched)

These lines are also output to the test
trace file, whether the test passes or not.

Note that expect() will still fail at the first failed
check, in line with previous behaviour.

Also I have flipped the wording of the assert
message functions (.*_MSG) to describe failures
not successes. This makes more sense as they are
only shown on assert failures.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D86792
2020-09-03 13:35:05 +01:00