YASL Request

[Patrick Venture]

On Fri, Apr 13, 2018 at 8:21 AM, Brad Bishop
<bradleyb at fuzziesquirrel.com> wrote:
>
>> On Apr 12, 2018, at 11:56 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
>>
>>
>> Some advantages I've found to this technique are:
>>
>> * There's no reduction of readability in the code
>
> This.
>
>> * You get test binaries that you can run independent of your test framework, as there isn't really a test framework, just autotools running your test binaries in parallel
>> * By extension, if you need to debug a failing test case, you can gdb the test binary directly without needing to comprehend the side-effects of the test framework on your test binary
>
> And this.
>
> Honestly these are my _real_ objections but I brought up runtime overhead because
> that is not subjective.  I just don’t like how the direction we are headed
> obfuscates things for developers that have a good understanding of standard libraries,
> tools, and language features (libc, libstd++, STL, GDB, etc...) and don’t have an
> understanding of the internals of GMock or the “techniques" its use drives into the
> code.  I expect there to be way more of the former (those up to speed on the standard
> libraries, tools, language features) than the latter (those comfortable working on
> a GMock inspired codebase).

I find a flaw in this logic that, because a developer would need to
learn something new, because as you say few people will be familiar
with gmock.  Every developer I've met tends to learn new things all
the time, and I specifically hadn't used c++ since 2004, and basically
learned it to contribute to OpenBMC, and I doubt I'd be an exception
to this.

>
> IMHO these concepts have a greater (positive) impact on the project overall than
> super-easy-unit-test writing.  I’d guess I’m in the minority, but hey…I have to
> speak my mind right?  I can certainly relate to the opposing viewpoint.