YASL Request

[Lei YU]

On Fri, Apr 13, 2018 at 11:21 PM, 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
>

By using gtest/gmock, it is the same that the test binary is generated and run
by autotools. You can use gdb to debug the failing tests as well.

> 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 get your point. And I have to admit that generally developers tend to
*directly* use standard libraries because they are familiar with that.
But I still want to point that by writing code that way:
1. It makes the code harder to test and thus likely to contain potential
   un-found bugs;
2. It is possible to write code that put too much function in some level,
   if the developer does not group the code well.

By using gmock, the developer is *forced* to split the code into pieces of
interfaces and functions, otherwise the code is un-testable.
This helps on grouping and writing testable code, and since it's tested it is
likely to reduce the number of potential bugs.
Althoug it does introduce runtime overhead, I expecte the overhead is tiny in
most cases.

I know you are not in favor of writing code that way, but I do prefer testable
code than the other.
In my previous experience, the unit test could cover most major logic of the
code to make sure the code is (at some level) correct and robust.

>
> 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.