This is an archive of the discontinued LLVM Phabricator instance.

Braindump of what an LLDB lit test might look like
Needs ReviewPublic

Authored by zturner on Sep 7 2016, 10:41 AM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

I was trying to brainstorm what a real test that currently exists might look like if converted to a lit-style test. Not even proposing we do this, just figured I would throw up what I came up with in case anyone wants to see something concrete. These tests come from lang/cpp/namespace. There is one .test file for each method in each existing .py file. This way everything gets run in parallel. A couple observations and musings:

  1. There is NO MAKEFILE. Usually this is going to be fine, as most Makefiles are trivial anyway and do nothing. If we wanted to take this idea further so that it works for our entire test suite, we would need a way to provide custom build settings. I envision happening through directives in each test file but there are some issues obviously. We'd have to figure it out.
  2. There are no skip / xfail directives. Again, we could design our own per-file directives for this.
  3. There's no manual invocation of the Python APIs. I actually think this is an advantage. It makes the tests easier to understand. Whether this is flexible enough to support everything that LLDB tests do is an open question. We could always provide a #script <label> directive and then embed some Python code below if we need to do something funky.
  4. The checks and directives are interspersed with the code. I think this makes it much easier to look at a test and digest what it does rather than having to click through many different files. Although sometimes a test is specifically testing something that has to do with multiple object files. I didn't try to address that here, but again, with the freedom to design whatever set of directives we need to, I think it's doable.
  5. Source code is reproduced in every file. This means every test will be compiling its own target. But in practice I think this will still be a speedup over our current state of affairs, where every test STILL recompiles its own target, but it does so serially. In the solution here, at least the compiler would be run in parallel for each test.

Again, this is just some very early high-level thoughts about what a test might look like. I mostly approached this from the angle of "what would allow this test to be the easiest to write and easiest to understand".

Diff Detail

Event Timeline

zturner updated this revision to Diff 70560.Sep 7 2016, 10:41 AM
zturner retitled this revision from to Braindump of what an LLDB lit test might look like.
zturner updated this object.
zturner added subscribers: Restricted Project, lldb-commits, rnk.
emaste added a subscriber: emaste.Sep 7 2016, 12:02 PM
tfiala added a subscriber: tfiala.Sep 10 2016, 6:58 PM