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.
Overview
Section titled “Overview”Network as Code uses the following testing components:
| yaml-lint | nac-validate | nac-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-validateandnac-testwere previously known asiac-validateandiac-test.
Together, these checks reduce risk by catching issues early and ensuring deployed state matches design intent.

Pre-Change Validation (nac-validate)
Section titled “Pre-Change Validation (nac-validate)”nac-validate provides two levels of pre-change quality gates:
- Syntax/schema validation: Verifies structure, required fields, and valid value types.
- Semantic/rule validation: Enforces policy and logical correctness through custom Python rules.
This prevents invalid or non-compliant configuration from reaching deployment stages.
What the schema does (syntax check)
Section titled “What the schema does (syntax check)”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.
What rules do (semantic check)
Section titled “What rules do (semantic check)”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.


Post-Change Validation (nac-test)
Section titled “Post-Change Validation (nac-test)”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.

How This Is Used in the Lab Guide
Section titled “How This Is Used in the Lab Guide”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.