How do unit-testing frameworks fit into automated testing and validation?

Unit tests become part of the codebase and run automatically on every change, following the code through commits, pull requests and review gates to QA and production.

* Tests live in the repository and gate the change at every stage: a failing test blocks it before a reviewer even looks. *

With a unit-testing framework, developers set up an environment where the code is tested automatically whenever it changes. The important shift is that tests live in the repository with the code, so:

• every commit and pull request triggers them,
• a failing test can block the code-review gate before a human even looks,
• the same tests run again in QA/test and before production.

This is especially useful for test-driven development (TDD), where you write the failing test first, then the code that makes it pass. The test then guards that behaviour from that point on.

The same principle carries over to infrastructure. If configuration is code, it can also have tests that run in the pipeline, which is what pyATS does for networks.

Go deeper:

• Martin Fowler — Test Driven Development — red, green, refactor in one page.
• Test-driven development — Wikipedia — the cycle and its trade-offs.