Test-Driven Development (TDD) Basics

Mental model

Normal development: you write the code, then (maybe) write some tests.

Test-driven development flips the order:

1. Red. Write a test for a function that does not yet exist. Run it. It fails. Of course — the function is not there.
2. Green. Write the simplest possible code that makes the test pass. Resist the urge to be clever.
3. Refactor. Clean up the code (rename, deduplicate, extract) without changing what the test checks. Run the test again to confirm you did not break anything.

Then write the next test. Repeat.

Cisco objective 1.3 (CCNAAUTO 200-901) says “Describe the concepts of test-driven development”. This topic is the description.

Why TDD is different from “writing tests”

Writing tests AFTER the code tests whether your code does what you built. That is useful but limited: you tend to only test the paths you remember writing. Edge cases slip.

Writing tests FIRST forces you to:

• Define success before you code. You have to say exactly what the function should do, in test form, before you can write a single line of implementation.
• Keep your functions small. Big functions are hard to test. The test comes first, so the function size is bounded by what you can describe.
• Catch regressions. If a later change breaks an earlier test, you know within seconds. No manual re-checking.
• Document behaviour. The test suite is executable documentation. Anyone reading the tests can see exactly what every function is supposed to do.

A tiny example

You want a function is_valid_vlan(id) that returns True for VLAN IDs 1 to 4094 and False otherwise.

Red: Write the test first.

# test_vlans.py
from vlans import is_valid_vlan

def test_vlan_1_is_valid():
    assert is_valid_vlan(1) is True

def test_vlan_4094_is_valid():
    assert is_valid_vlan(4094) is True

def test_vlan_0_is_invalid():
    assert is_valid_vlan(0) is False

def test_vlan_4095_is_invalid():
    assert is_valid_vlan(4095) is False

def test_vlan_negative_is_invalid():
    assert is_valid_vlan(-1) is False

Run pytest. Five tests, five failures: there is no vlans module.

Green: Write the simplest vlans.py.

# vlans.py
def is_valid_vlan(id):
    return 1 <= id <= 4094

Run pytest again. Five passes. Done.

Refactor: The function is already one line. Nothing to clean up. Move on to the next test (e.g., “VLAN ID must be an int, not a string”).

Where TDD helps network engineers most

• Parsing scripts. You write a function that extracts the interface name from a show interface line. Tests cover the normal case, the with-description case, the sub-interface case. When vendor firmware changes the output format and your script breaks, you see exactly which test fails and why.
• Config generators. You generate a Cisco config from a template. Tests check that specific lines appear for specific inputs. You can refactor the template without fear.
• API wrappers. You wrap a REST API in a few helper functions. Tests mock the HTTP call and check that your wrapper handles 200, 404, 429 and timeouts correctly.

When TDD is overkill

• Throwaway scripts you will delete in an hour.
• Exploration code where you do not yet know what the function should do.
• Pure configuration (YAML files, Ansible inventory): there is nothing to assert.

Common pitfalls

• Writing tests after the code and calling it TDD. It is not; the discipline is in the order.
• Writing one giant test that checks everything. Each test should check one thing. When it fails you know exactly what broke.
• Testing the implementation instead of the behaviour. A test should pass or fail based on what the function does to its inputs, not how it does it internally. Otherwise every refactor breaks the test.
• Not running the test first. If you skip Red, you never see the test fail, so you do not know if the test actually tests what you think.

FAQ

Does TDD slow me down? Short term: yes, by maybe 20%. Long term: no, because you spend less time debugging and are less afraid to refactor. For a one-off 50-line script, skip it. For anything that will be around for a quarter or more, TDD pays back.

What test framework should I use for Python? pytest. Simpler syntax than the standard library’s unittest. Covered in python-unit-tests-with-pytest in a later phase.

What about network simulation tools like pyATS? pyATS is for TESTING network behaviour (did my OSPF converge in under 500 ms?). TDD here is about testing the Python / Ansible / Terraform code you WRITE. Both are useful; different scope. pyATS appears in Cisco objective 5.3.

Is TDD the same as BDD? No. BDD (Behaviour-Driven Development) uses human-readable test descriptions (Given/When/Then) and is targeted at non-developers reviewing specs. TDD is a developer practice. Related but not identical.

Does TDD apply to Ansible playbooks? Partly. You can test playbooks with Molecule (install separately). The role is written first with its tests; the TDD loop is slower because each test spins up a container. Still worth it for roles used by many teams.