Blog post written by Gilbert Moisio, expert on network automation and Senior consultant, specialist on knowledge acquisition, technologies and methodologies. He published several papers about automation, Software-Defined Networking and Wi-Fi. His website.
There are many solutions for performing TDD (Test Driven Development) unit testing as part of NetDevOps debugging, but Robot Framework is my preferred generic Acceptance Test Driven (ATDD). Its testing capabilities can be extended with libraries implemented in Python or Java. Initially, the framework was developed by Nokia Networks. Today, it is sponsored by the Robot Framework Foundation.
Insofar as we speak of “Network as Code” or “Infrastructure as Code”, it is because we consider that all that is necessary to activate the infrastructure exists in software form. In the software world, Agile and DevOps approaches are widely adopted. We know that tests are an important part of the Agile approach for the “Definition of Done” of a “User Story”.
I. How to create a “User Story”?
To create a “User Story”, it is generally necessary to break it up into tasks. There is not only one way of conceiving things, but as far as I am concerned, I consider that the tests which validate a task must remain as close as possible to it.
Most often, these are unit tests. If I use Ansible to carry out the task, the tests are integrated into its Playbooks.
It’s at the level of abstraction of the “User Story” that I use Robot Framework. At this level, it is most often acceptance tests that are necessary for validation. They can be conceived in different forms, includind the BDD approach in Gherkin language (Given/When/Then).
For acceptance tests, it is common to execute actions which pass through the network infrastructure but which target servers or peripheral equipment.
To do this, I use some “standard” librairies, but often “external” libraries like SeliniumLibrary to access web servers (remember to activate the “Allow remote automation” function of Safari on Mac), SSHLibrary for connect to equipment or NcclientLibrary to make NETCONF connections.
But I suggest you study and detail a slightly more complex and interesting case. Suppose we have a “User Story” that focuses on the ZTP (Zero Touch Provisioning) implementation.
This “User Story” will have integrated their own definitions of “Done” with unit tests.
Consider that, for this “User Story”, the acceptance test consits of accessing each of the devices and verifying that the OS version corresponds to an expected reference. This will prouve that the Out-Of-Band infrastructure is functional, that the minimum configuration has been injected that any automatic OS updates have been performed…
For reasons of readability, all the elements were put in the same robot file, which is not the case in my complete library. When we want to share resources and variables between several robot files, we externalize the information in a file containing the resources and another file containing the variables.
A resource file has the same syntax as a robot file, except that it does not contain tests.
Concepts are easy to guess and you can imagine that it is possible to enrich this library.