[Lldb-commits] [PATCH] D46005: [test] Add a utility for dumping all tests in the dotest suite
Zachary Turner via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Apr 24 10:25:45 PDT 2018
zturner added a comment.
In https://reviews.llvm.org/D46005#1077029, @labath wrote:
> In https://reviews.llvm.org/D46005#1077013, @zturner wrote:
> > I thought the intention was going to be parallelize at file-granularity rather than method granularity, since the whole point of grouping tests together into classes is that they can share similar set up and tear down which may be expensive to perform multiple times. If we're going to parallelize at method-granularity, I would rather have one .py file per method.
> Hm... good question. I don't think any of our current tests take advantage of this possibility (sharing set-up code). Well.. except if you don't count bringing up the entire dotest machinery as set-up code (which does take a non-zero amount of time, but hopefully that can be brought down once we move everything to lit).
> However, maybe this does need more discussion.
> FWIW, I think that we shouldn't enforce the one-test-method-per-file completely rigidly. It may make sense to separate out some of the things, but I think that our tests often need some similar utility functions, which are too specific to put in some generic library, and it's easier to share these if they are in the same file. Having multiple tests in the same file also reduces the boiler plate and avoids another round of modifying each test file. (I think even lit acknowledges the usefulness of having logically separate tests in the same file (CHECK-LABEL)).
I agree we shouldn't enforce one test per file. I just think it's may be worth only //parallelizing// at the file level. If you want two tests to be able to run in parallel, perhaps we should say that those tests must be in different files (perhaps even in the same directory).
LLVM's lit / FileCheck tests often also have multiple tests in one file. But all tests in the same file run sequentially.
More information about the lldb-commits