Open Stack

On 10 February 2013 08:15, John Griffith <john.griffith at solidfire.com> wrote:
> Hey Everyone,
>
> I just wanted to get some thoughts going around our unit testing process.
> The good thing is we seem to do a pretty good job of requiring unit tests
> with patches, the bad thing is I'm not sure I think our strategy on how we
> implement those unit tests is the best.  There are a couple of things I've
> been noticing lately that is somewhat annoying for me.
>
> First, I guess I have my own view of what a Unit test is and maybe that's
> not in line with the rest of the community.  My opinion is that a unit test
> should be the smallest white box test possible on a piece of code, and the
> boundary of a unit test should be the class the code that's being exercised
> belongs/lives in.  This means that for things like db calls, calls out to
> other modules etc that fakes, or mocks should be used to provide the inputs
> and responses needed by the code under test.  This of course requires a bit
> more discipline around consistency in our public interfaces which IMO we
> desperately need as well.

I too would like an example. However, while I'm hugely enthusiastic
about test fakes, mocks are massively overused IMNSHO: Mocking
anything that isn't a super stable interface(*) is just tech debt
waiting to bite. I'd like to see us publish tested fakes [by which I
mean a fake which is owned by the service it fakes, and cross-tested
for identical behaviour as part of that services own tests], rather
than mocking out things from another service.

*: Consider just -how- big the change to Python3 will be, and you'll
see that nearly every mock used that has any interaction with unicode
vs string will end up being non-representative of actual behaviour.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services