YASL Request

[Patrick Venture]

Because there are many patches enabling this, here is the order:

https://gerrit.openbmc-project.xyz/#/c/10109/
https://gerrit.openbmc-project.xyz/#/c/10129/
https://gerrit.openbmc-project.xyz/#/c/10157/
https://gerrit.openbmc-project.xyz/#/c/10159/
https://gerrit.openbmc-project.xyz/#/c/10052/
https://gerrit.openbmc-project.xyz/#/c/10166/

I need to rebase and push the last one so it won't require a merge,
but that's not urgent.  I'll be adding at least two more patches after
lunch which will further propagate the SdBusInterface that enables
testing without requiring more injections.

If you're curious what the tests look like so far:
https://gerrit.openbmc-project.xyz/#/c/10048/

Patrick

On Sun, Apr 15, 2018 at 7:50 PM, Lei YU <mine260309 at gmail.com> wrote:
> 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.