<br><br><div class="gmail_quote">On Tue, Oct 2, 2012 at 2:49 AM, Philip Craig <span dir="ltr"><<a href="mailto:reviews@llvm-reviews.chandlerc.com" target="_blank">reviews@llvm-reviews.chandlerc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Which part of the unit tests do you think is bulky? The initial infrastructure is mostly a copy from StmtPrinterTest.cpp. This shouldn't need to be changed when adding tests (and probably should be moved to some common code), so the size of the actual tests is similar to what is needed for FileCheck.<br>
</blockquote><div><br></div><div>I think the code except actual tests is not needed if your task can be solved using something simpler. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  I used FileCheck for the tests for my standalone dumper, and had a couple of problems. It:<br>
  * uses the same compiler options and language for the whole test<br></blockquote><div>You can use multiple RUN: lines with different -D defines, and #ifdef blocks in the code.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  * currently ignores leading whitespace so can't test indentation<br></blockquote><div>You can use --strict-whitespace option and regex syntax for CHECK: lines. For example, as in this .sh script:</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_quote"><div><div><font face="courier new, monospace">#!/bin/bash</font></div></div></div><div class="gmail_quote"><div><div><font face="courier new, monospace">echo "   test" | FileCheck --strict-whitespace $0</font></div>
</div></div><div class="gmail_quote"><div><div><font face="courier new, monospace"><br></font></div></div></div><div class="gmail_quote"><div><div><font face="courier new, monospace"># CHECK: {{^  test$}}</font></div></div>
</div></blockquote><div class="gmail_quote"><div>It detects wrong leading whitespace:</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div><div><font face="courier new, monospace">./test.sh:4:10: error: expected string not found in input</font></div>
</div></div><div class="gmail_quote"><div><div><font face="courier new, monospace"># CHECK: {{^  test$}}</font></div></div></div><div class="gmail_quote"><div><div><font face="courier new, monospace">         ^</font></div>
</div></div><div class="gmail_quote"><div><div><font face="courier new, monospace"><stdin>:1:4: note: scanning from here</font></div></div></div><div class="gmail_quote"><div><div><font face="courier new, monospace">   test</font></div>
</div></div><div class="gmail_quote"><div><div><font face="courier new, monospace">   ^</font></div></div></div></blockquote><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  * is fragile if you want to test the SourceRange dumping<br></blockquote><div><br></div><div>Yes, these tests are fragile to some extent, if you use them to test source locations. When your add or remove test code, you need to change CHECKs after these lines. But these problems are easy to detect and fix (if you're not going to write thousands of lines of tests in one file). And they are relatively easy to avoid, if you add new tests only to the end of the file.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  The ability to use an AST matcher for unit tests also makes them slightly more convenient (I realise there'll be a command line option for this eventually).<br></blockquote><div><br></div><div><div>I'm not sure what convenience do you mean, I see mostly increased complexity.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  The main advantage I can see for FileCheck is that it provides more flexible matching.<br></blockquote>
<div><br></div><div>The next one is that it's quite simple and you can expect a certain level of correctness and stability from it. And you probably want your test code to be as simple, as it can be, so anyone can easily read, understand and change it. And you probably don't want too many dependencies in your tests, so you don't have to catch bugs in tests when any library you rely on, changes.</div>
<div><br></div><div>So I'm definitely for using FileCheck in this case, but it's only me, others may disagree.</div></div><br clear="all"><div>-- </div><div>Regards,</div><div>Alex</div>