Test Driven Development

What it is

Test driven development, or TDD, is a way of working in which you write a failing test before you write the code that makes it pass.

The test describes what the code should do. The code is then written to meet that description, and nothing more.

The aim is code that is correct from the start, easy to change and covered by tests. Each test also acts as a small piece of documentation.

How it works

TDD runs as a short loop that repeats for every small piece of behaviour.

The red, green, refactor cycle

1. Red. Write a test for a feature that does not exist yet. Run it and watch it fail.
2. Green. Write the simplest code that makes the test pass. Run all tests again.
3. Refactor. Tidy the code and remove duplication. Run the tests to prove that nothing broke.

The failing first run matters. It proves the test can actually fail, so a later pass means something.

A small example

Suppose you need a function that checks whether a VLAN ID is valid. You write the test first, using the standard unittest module.

import unittest

from vlan import is_valid_vlan


class TestVlan(unittest.TestCase):
    def test_valid_range(self):
        self.assertTrue(is_valid_vlan(100))

    def test_zero_is_invalid(self):
        self.assertFalse(is_valid_vlan(0))

    def test_too_high_is_invalid(self):
        self.assertFalse(is_valid_vlan(4095))


if __name__ == "__main__":
    unittest.main()

At first the module vlan does not exist, so the tests fail. You then write the smallest function that passes them.

def is_valid_vlan(vlan_id):
    return 1 <= vlan_id <= 4094

Later you might refactor the function or add tests for text input. The tests tell you at once if you break something.

Types of test

TDD is built mainly on unit tests, because they are quick enough to run after every small change.

Test doubles

A unit test should not depend on a real network device or a live API. You replace the outside dependency with a fake object, often called a mock.

A mock returns a prepared answer, so the test runs fast and gives the same result every time. Python provides unittest.mock for this purpose.

Benefits and limits

• Bugs are found early, when they are cheap to fix.
• The design tends to be simpler, because you write only code that a test demands.
• You can refactor with confidence, because the test suite catches regressions.
• Tests run automatically in a CI pipeline on every change.

TDD takes more time at the start. The tests also need maintenance, and poor tests give false confidence.

Where tests fit in automation

Network automation code is still code. A script that builds a configuration or parses a device reply needs tests like any other program. A test can feed in a saved sample reply and check the result.