<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 8, 2019 at 12:46 PM David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">David Blaikie via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> writes:<br>
<br>
> I have a bit of concern about this sort of thing - worrying it'll lead to<br>
> people being less cautious about writing the more isolated tests.<br>
<br>
That's a fair concern.  Reviewers will still need to insist on small<br>
component-level tests to go along with patches.  We don't have to<br>
sacrifice one to get the other.<br>
<br>
> Dunno if they need a new place or should just be more stuff in test-suite,<br>
> though.<br>
<br>
There are at least two problems I see with using test-suite for this:<br>
<br>
- It is a separate repository and thus is not as convenient as tests<br>
  that live with the code.  One cannot commit an end-to-end test<br>
  atomically with the change meant to be tested.<br>
<br>
- It is full of large codes which is not the kind of testing I'm talking<br>
  about.<br></blockquote><div><br></div><div>Oh, right - I'd forgotten that the test-suite wasn't part of the monorepo (due to size, I can understand why) - fair enough. Makes sense to me to have lit-style lightweight, targeted, but intentionally end-to-end tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Let me describe how I recently added some testing in our downstream<br>
fork.<br>
<br>
- I implemented a new feature along with a C source test.<br>
<br>
- I used clang to generate asm from that test and captured the small<br>
  piece of it I wanted to check in an end-to-end test.<br>
<br>
- I used clang to generate IR just before the feature kicked in and<br>
  created an opt-style test for it.  Generating this IR is not always<br>
  straightfoward and it would be great to have better tools to do this,<br>
  but that's another discussion.<br>
<br>
- I took the IR out of opt (after running my feature) and created an<br>
  llc-style test out of it to check the generated asm.  The checks are<br>
  the same as in the original C end-to-end test.<br>
<br>
So the tests are checking at each stage that the expected input is<br>
generating the expected output and the end-to-end test checks that we go<br>
from source to asm correctly.<br>
<br>
These are all really small tests, easily runnable as part of the normal<br>
"make check" process.<br>
<br>
                     -David<br>
</blockquote></div></div>