How to Test the AI Components Developed in the AI Engineering From Scratch Repository

Every AI component in the rohitg00/ai-engineering-from-scratch repository includes a self-contained test suite in code/tests/ that you can execute using standard language-specific test runners, validated by the audit_lessons.py linter and CI pipeline.

The repository is structured as a modular curriculum where each lesson under phases/ functions as an isolated AI component with its own implementation, documentation, and verification suite. When you test the AI components developed in this codebase, you leverage a standardized directory layout and automated auditing tools that enforce quality across Python, TypeScript, Rust, and Julia implementations.

Repository Testing Philosophy

The curriculum follows a lesson-autonomous architecture. Each directory under phases/ (for example, phases/19-capstone-projects/35-gpt-model-assembly) contains everything needed to build, run, and verify a specific AI capability.

This isolation ensures that changes to one component—such as a GPT model implementation—cannot silently break another. The scripts/audit_lessons.py file enforces three critical conventions:

• Minimum test coverage: Every lesson must contain at least five unit tests inside code/tests/
• Executable demos: The main.<lang> entry point must run to completion without interactive input
• CI compliance: All tests must pass in the automated pipeline defined in .github/workflows/curriculum.yml

Step-by-Step Guide to Testing AI Components Locally

You can verify any AI component without installing the entire curriculum. The process uses the language’s default testing framework, aligning with the repository’s stdlib-first dependency policy.

1. Navigate to the Lesson Directory

Change into the specific lesson folder containing the component you want to test:

cd phases/19-capstone-projects/35-gpt-model-assembly

2. Run the Unit Tests

Execute the test suite using the language-specific discovery command. For Python lessons, unittest discovers all files matching test_*.py in code/tests/:

python -m unittest discover -s code/tests -p "test_*.py"

The runner reports individual test results and returns a non-zero exit code if any assertion fails.

3. Verify End-to-End Execution

Confirm the component runs correctly as a self-terminating demo:

python code/main.py

A successful execution prints a summary and exits with status 0, indicating the AI pipeline completed without errors.

4. Run the Repository-Wide Audit (Optional)

Validate cross-lesson integrity—including documentation links and quiz formatting—using the linting script:

python scripts/audit_lessons.py

The script prints a concise report (e.g., "0 issues") and exits with a non-zero code if it detects missing tests or malformed metadata.

Language-Specific Testing Commands

While Python uses unittest, other languages in the curriculum follow the same code/tests/ structure but invoke their native runners:

TypeScript: Discovers and executes tests using Node.js built-in test runner

cd phases/04-computer-vision/12-video-understanding
npx tsx --test

Rust: Runs Cargo’s native test harness

cargo test

Julia: Executes tests within the project environment

julia --project=test

Regardless of language, the audit_lessons.py script expects the same layout: a non-empty code/ folder containing both implementation files and a tests/ subdirectory.

CI/CD Integration and Automated Validation

The .github/workflows/curriculum.yml file defines a continuous integration pipeline that executes on every push. This workflow automatically runs scripts/audit_lessons.py across all lesson directories and executes language-specific test commands to guarantee the repository remains in a green state.

Because the audit script checks for broken internal links, malformed quiz JSON files, and the presence of the required five unit tests, it acts as a gatekeeper that prevents broken AI components from merging into the main branch.

Summary

• Navigate to the specific lesson directory under phases/ to work in isolation
• Execute unit tests using standard language runners like python -m unittest discover or cargo test
• Validate end-to-end functionality by running code/main.py (or equivalent) to ensure self-termination
• Audit the entire repository with python scripts/audit_lessons.py to catch cross-cutting issues
• Trust the CI pipeline in .github/workflows/curriculum.yml to enforce these standards automatically

Frequently Asked Questions

How many unit tests must each AI component include?

According to the audit_lessons.py validation logic, every lesson must contain at least five unit tests inside its code/tests/ directory. The audit script counts test cases and fails validation if this minimum is not met.

Can I test a single lesson without cloning the entire curriculum?

Yes. Because each lesson is autonomous, you can copy or navigate to a single lesson folder (e.g., phases/19-capstone-projects/35-gpt-model-assembly) and run its tests independently using the standard language-specific command. No dependencies on sibling lessons exist.

What happens if the audit script detects issues?

scripts/audit_lessons.py returns a non-zero exit code and prints a detailed report listing broken links, missing quiz files, or insufficient test coverage. In the CI pipeline defined in .github/workflows/curriculum.yml, this exit code blocks the merge, ensuring only validated components reach the main branch.

Are the Python tests compatible with pytest instead of unittest?

The repository standardizes on the built-in unittest module to maintain zero external dependencies. While you could technically run pytest discovery on the code/tests/ directory, the official audit_lessons.py script and CI pipeline specifically validate the presence of unittest structures.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}