Dumb driver

[dbarrosop]

This implements a generic mock driver that anybody can use to mock workflows/tools without having to mock a real device. The way it works is as follows:

1. You create a device using the MockDriver and passing a path and a profile.
2. The path will be used to find mocked data so if you do d.get_facts() it will try to find $PATH/get_facts.1 and return the json inside. If you do d.get_facts() again it will try to find $PATH/get_facts.2.

You can check the test to see how it behaves.

Immediate uses for this would be to properly test napalm-ansible modules, napalm-yang and I bet napalm-salt and others could benefit of this.

[dbarrosop]

You can see an example here:

https://github.com/napalm-automation/napalm-yang/pull/70/files#diff-eccaf564661c1c607299e14397d4a5dfR79

[dbarrosop]

More example. Here you can see how to test ansible workflows:

napalm-automation/napalm-ansible#66

Workflow is flexible enough even to simulate failures.

[ktbyers]

It might be nice to also support a named way to do this (if there is some logical way to do it).

For example, in addition to:

get_facts.1
get_facts.2

also support:

get_facts.strange_lldp_output_ios

if you set some variable like testname. Of course, we would need to figure a way to map this to other tools like ansible and Salt.

I am a bit worried as tests get more complex just sequencing indexes might be hard to keep track of (of course we can add this later).

[ktbyers]

Need to inherit from (object) or would use old-style classes in PY2 (which we don't want to do). So should be

class MockDevice(object):

[dbarrosop]

Right, I always get them wrong...

[ktbyers]

Should it raise an exception here if profile is not set (i.e. a blank list)?

[dbarrosop]

Not sure, I think it's fine to avoid checking here. I might want to test that napalm-yang returns a meaningful error or that behaves in a certain way if the profile is invalid.

[ktbyers]

Class needs to inherit from object. I just checked pytest and it looks like they just (8 days ago merged PR to deprecate old-style classes).

https://github.com/pytest-dev/pytest/pull/2525/files

I think safer for us is to consistently use new-style classes i.e. inherit from object in the tests.

[dbarrosop]

Yes, completely agree. I always get them wrong though :(

Would be great if __future__ had something like print_functions to force the new style...

[dbarrosop]

if you set some variable like testname

So that feature is not really for that use case. That feature is for supporting multiple calls to the same method returning different results. For example, let's say you are writing a monitoring tool and need to call get_interfaces multiple times to test you are updating your db properly or that your configuration management system changes the hostname properly and reports it to some central tool.

What you are suggesting would be accomplished instead by having different mocked devices. Something like:

mocked/
    ios_12/
        get_lldp_neighbors.1
    ios_12_no_neighbors/
        get_lldp_neighbors.1
    ios_12_weird_output/
        get_lldp_neighbors.1

For example:

https://github.com/napalm-automation/napalm-ansible/pull/66/files#diff-51bd545870274958d2bca976325f59ceR2