First Stage of sdbusplus mocks

First Stage of sdbusplus mocks

[Patrick Venture]

Everyone;

Mocks:
https://gerrit.openbmc-project.xyz/#/c/10046

I've only implemented mocks for sdbusplus::bus::bus and
sdbusplus::message::message (append() & read()) at this point.  Next
I'll be tackling other parts of sdbusplus.

Basically you can now verify the calls into sdbusplus, and the
parameters passed to the messages.  Which is pretty valuable.
However, nearly all of openbmc was written without unit-testing in
mind, so few things have easy injection points.  This'll have to
change over time as unit-tests become prolific inside openbmc.   In a
previous email I talked about using interfaces in libraries for
everything so that you could get mocks for free :D  That's the way we
need to go, and so I'm going to do some basic library implementations
with mocks and see how people like them (or dislike them).  The idea
being, anything you're calling should be mocked so you can easily test
the code. :)  Easily being key.

Examples of usage:
https://gerrit.openbmc-project.xyz/#/c/10048

Please take a look and provide some feedback.  The sdbuplus mocks
aren't compiling in the CI, but did compile locally (as obvious by my
usage of them in a unit-test and a live image).  So I would appreciate
some insight into what might be going on there.

Next on my plate for attack:
sdbusplus::server::interface::interface
sdbusplus::server::manager::manager
sdbusplus::server::object::details...
sdbusplus::server::transaction...

and seeing what openbmc daemon is easiest to rip apart into testable
units, to provide more examples.  phosphor-pid-control doesn't compile
with upstream, otherwise I'd start there as I'm familiar with the
daemon and it was written in lots of pieces for testing.

Regards,
Patrick

Re: First Stage of sdbusplus mocks

[Patrick Venture]

Hi everyone,

Just about to head on a quick vacation.  Wanted to reach out and see
if I can get some more feedback on the progress made to introduce
testability through interfaces in sdbusplus.  I'd like to start
writing tests that use it, but can't so feedback would be appreciated.
And thanks to Emily and Lei who have been looking at it.

https://gerrit.openbmc-project.xyz/#/q/topic:gtest-gmock-ready-for-review+(status:open+OR+status:merged)

Patrick

On Tue, Apr 10, 2018 at 1:12 PM, Patrick Venture <venture@google.com> wrote:
> Everyone;
>
> Mocks:
> https://gerrit.openbmc-project.xyz/#/c/10046
>
> I've only implemented mocks for sdbusplus::bus::bus and
> sdbusplus::message::message (append() & read()) at this point.  Next
> I'll be tackling other parts of sdbusplus.
>
> Basically you can now verify the calls into sdbusplus, and the
> parameters passed to the messages.  Which is pretty valuable.
> However, nearly all of openbmc was written without unit-testing in
> mind, so few things have easy injection points.  This'll have to
> change over time as unit-tests become prolific inside openbmc.   In a
> previous email I talked about using interfaces in libraries for
> everything so that you could get mocks for free :D  That's the way we
> need to go, and so I'm going to do some basic library implementations
> with mocks and see how people like them (or dislike them).  The idea
> being, anything you're calling should be mocked so you can easily test
> the code. :)  Easily being key.
>
> Examples of usage:
> https://gerrit.openbmc-project.xyz/#/c/10048
>
> Please take a look and provide some feedback.  The sdbuplus mocks
> aren't compiling in the CI, but did compile locally (as obvious by my
> usage of them in a unit-test and a live image).  So I would appreciate
> some insight into what might be going on there.
>
> Next on my plate for attack:
> sdbusplus::server::interface::interface
> sdbusplus::server::manager::manager
> sdbusplus::server::object::details...
> sdbusplus::server::transaction...
>
> and seeing what openbmc daemon is easiest to rip apart into testable
> units, to provide more examples.  phosphor-pid-control doesn't compile
> with upstream, otherwise I'd start there as I'm familiar with the
> daemon and it was written in lots of pieces for testing.
>
> Regards,
> Patrick