Closed dbarrosop closed 7 years ago
You can see an example here:
More example. Here you can see how to test ansible workflows:
https://github.com/napalm-automation/napalm-ansible/pull/66
Workflow is flexible enough even to simulate failures.
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).
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:
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:
MockDriver
and passing apath
and aprofile
.d.get_facts()
it will try to find$PATH/get_facts.1
and return the json inside. If you dod.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 betnapalm-salt
and others could benefit of this.