<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 14, 2013 at 1:04 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="cremed">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> I think the cost of carrying it around is essentially zero. I'm happy to do<br>
> any of the maintenance. People who don't know how to use it or want to learn<br>
> how to use it don't need to use it. If it isn't making their job of writing<br>
> tests sufficiently easier to justify, then they don't use it. I see this as<br>
> a good pattern.<br>
<br>
</div>That is not the case. If the test finds any bug at all, people have to<br>
look at the testcase and see if it is failing.<br>
<br>
Even if not bug is found, someone doing refactoring has to change the<br>
test to use the new apis.</blockquote><div><br></div><div>On IRC, Rafael indicated he would like to understand the specific use case I had in mind better. I'm still working on a concrete example, but figured I'd clarify more than my initial mail did.</div>
<div><br></div><div>I'm working on the pass manager. I need a way to test that specific passes in the pass manager are being run and invalidated appropriately based on the dependencies between them and the caching infrastructure. Verifying this can be done in two ways:</div>
<div><br></div><div>1) I can add non-trivial code which essentially dumps the state at each point, along with a command line tool and collection of fake passes, and use FileCheck against this code to verify things. This works for asserts builds but not for no-asserts builds, and generally feels like working around a missing feature in our testing infrastructure. This is the same reasons we don't use FileCheck and state serialization to test our DenseMap implementation.</div>
<div><br></div><div>2) I can write a unittest using gtest with a completely custom collection of N passes written for every single test, each with a different set of integer output parameters that are incremented and decremented at the right points, and then a verification of their final value. This will work, but will be hard to debug (the failure is detected long after it happens) and very verbose.</div>
<div><br></div><div>3) I can use gmock to write a specific set of expected events for a pass and verify that they happen. It was specifically designed to make verifying this kind of interaction explicit with little boilerplate and decent error messages when it fails.</div>
<div><br></div><div>I'll try to come up with an example of #3 this evening or tomorrow.</div><div><br></div><div>-Chandler</div></div></div></div>