Skip to content

Understanding Testing Toolkit

Testing is a core part of Branch as Code and is applied throughout the delivery lifecycle. In this section, we focus on the purpose of each testing capability and where it is used in the workflow.

Network as Code uses the following testing components:

yaml-lintnac-validatenac-test
Validates YAML syntax and formatting.Validates the data model for syntax and semantics against schema and rules.Validates post-deployment network state against intended configuration.

Note: nac-validate and nac-test were previously known as iac-validate and iac-test.

Together, these checks reduce risk by catching issues early and ensuring deployed state matches design intent.

Overview of testing

nac-validate provides two levels of pre-change quality gates:

  1. Syntax/schema validation: Verifies structure, required fields, and valid value types.
  2. Semantic/rule validation: Enforces policy and logical correctness through custom Python rules.

This prevents invalid or non-compliant configuration from reaching deployment stages.

The schema defines the contract for the data model. At minimum, it describes:

  • Expected object structure and nesting
  • Required and optional fields
  • Accepted data types (for example string, integer, list)
  • Allowed values and ranges (for example enums, min/max)

If YAML is well-formed but does not match this contract, schema validation fails. In other words, schema validation ensures the model is not only valid YAML, but also valid Branch as Code input.

Rules validate intent and policy beyond basic schema structure. They are typically implemented as Python checks and are useful for constraints such as:

  • Naming and convention enforcement
  • Environment-specific guardrails
  • Cross-field logic validation
  • Compliance requirements that cannot be expressed by type checks alone

This complements the schema by ensuring the model is both technically valid and operationally acceptable.

NaC Validate syntax NaC Validate rules

nac-test verifies that the deployed Meraki Dashboard configuration matches the desired state defined in the data model.

It uses templated automated tests and produces reports (for example HTML and JUnit/XML outputs) that can be consumed by CI/CD systems and operations teams.

Post Change Test Results

In this learning lab, detailed test execution steps are covered directly in the lab guide workflows.

The lab guide includes prebuilt GitHub Actions jobs/workflows that perform:

  • Syntax validation
  • Semantic validation
  • Automated post-deployment testing

This chapter is intentionally conceptual, while the lab guide provides the operational, step-by-step execution details.