Little Known Ways to Behavior Driven Ansible Testing — Part 1

in #behaviordriven7 years ago

This is the first part of two part post …

As a developer in order to implement CI(Continuous Integration) properly one of the first things that you should be implementing Unit test code which goes hand in hand with TDD(Test Driven Development).

Basically, there are three types of test that are should be done by the developers of an application.

  1. Unit Testing
  2. Integration Testing
  3. Acceptance Testing

Another practice in the Agile movement is BDD(Behavior Driven Development) this is not always implemented in the developers arsenal but if you are doing agile development I think it goes hand in hand with your agile stories.

Unit Testing

Unit test focus on a small block of code basically that is one of the reason it is called Unit Testing you are basically testing a function or an object.

Python Unit Test

pythonUnitTest.jpg

Read more of Python Unit Testing http://pymbook.readthedocs.io/en/latest/testing.html

Javascript Unit Testing

javascripttesting.jpg

Go Unit Testing

goTestingExamples.jpg

Read Alex’s Blog post https://blog.alexellis.io/golang-writing-unit-tests/

TDD(Test Driven Development)

TDD or Test-Driven Development is a process for when you write and run your test this does not happen as much it should because it seems developers sometimes don’t have a clear picture of what they coding, being lazy or basically would like to throw it over the fence to an oncoming developer or even DevOps.

If you are not using TDD then that means testing is a second-hand citizen in your environment TDD is simply before you start writing the actual code of the application you will write the test first.
I can tell you one the most frustrating thing is to either document someone else’s work or to write the unit test for another developer's code, I have been tasked to do that before and I can tell you that it is a nasty and unthankful job.

It means you must read through their code and then write a test for each unit, the problem with this is normally you are not given the premise of what the application actually does.
The TDD process consists of the following steps:

  1. First write your test remember you should not have written any code.
  2. Run your test, your test should fail because all you have is your framework or function definition.
  3. Run your test of course your test should fail.
  4. Now write the real code to make the test pass.

It is really that simple, if more developers start practicing the TDD approach of developing there will be a more test coverage which leads to better code, less bugs and less headaches for the next developer who has to take over their code.

BDD(Behavior Driven Development)

Behavior Driven Development primary focus should relate to the business behavior of the developer’s code.
This is key to quality code as the Business Owner or Product Owner works with the developer in order to create the application to correct way the first time around or at least the second time.

This is real agile at work now all of the above processes still need to be done but in a nut shell, the PO and when I say PO I say it in the sense of the person who would be the user of the system, not just the coined PO because this person has great knowledge of the technology.

Watered Down Steps To BDD:

The business person specifies behaviors they want to see in the system.
The developer asks questions based on their understanding of the system, while also writing down additional behaviors needed from a development perspective.

I know at this point you are probably saying OMG … I thought this was post was about Ansible Behavior Driven Testing.
It is but I wanted to give some a simple foundation for Operation, SysAdmins and Security Automation Specialist as the majority of DevOps seemed to think mostly about Devs with the NoOps attitude.
But I digress as that is a full post in itself …

In the beginning of this post, I talked about testing and how it relates to developers but we have not touched on the idea of Infrastructure-As-Code which is normally done by Operations, SysAdmin, Security Admins.
The nature of automation has now deemed that you become a developer if you want to stay in this industry.

So I needed to go over development practices as you are now writing code … Is that not what a developer do?

In the next post if you are using Ansible you will learn how to test your Ansible Playbooks in BDD style.

Additionally I will touch on some of the other tools like Chef, ServerSpec, Vagrant, and Docker.