<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 10:43 AM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We should be covering this using API tests that make an example like the one above and setting breakpoints in the inline header file. We have many tests for this. It is hard to get compilers to generate things that you can put in unit tests since they often change.<br>
<br><br></blockquote><div><br></div><div>What I mean is, there's a lot of magic that happens between the high level of the API test and the low level SymbolFile plugin.  And because of all that, you can't really write an API test or set of API tests that answers the question "Is the SymbolFile plugin implemented correctly?"  You can write some that test whether specific features of the debugger work correctly.  But only with the inputs you've specified.</div><div><br></div><div>For someone implementing a SymbolFile plugin, there's a lot of work that goes into understanding the expectations of the class and what the methods are supposed to return in different scenarios.  Having API tests doesn't really help with this.  On the other hand, if when designing the SymbolFile plugin architecture, you decide "if `check_inlines` is true, then the resulting SymbolContextList should satisfy some property", that's very easy to check with a unit test with just 5-10 lines of C++, and when you have a large collection of these tests, it becomes very easy for someone implementing a new one to figure out how to make everything work, or making changes to an existing SymbolFile without breaking anything (including things that someone didn't have the foresight to write an API test for).</div></div></div>