Continuous Integration and Automated Testing

In 2000, a software team might spend three months developing features independently, then convene for a week-long integration sprint — a period of intense, stressful debugging as all the branches were merged and the inevitable conflicts resolved. This was called integration hell.

The observation that made CI possible was simple: if integration is painful because you do it rarely, do it constantly. If you merge every change immediately and check it automatically, integration never accumulates into a crisis.

Continuous Integration means every developer merges their changes into the shared codebase at least once per day, and every merge automatically triggers a build and test run. Problems are caught within minutes, while the change is still fresh in the developer's mind.

What CI is not

CI is frequently confused with CD (Continuous Delivery or Continuous Deployment). They are related but distinct:

In this module we focus on CI. Delivery and deployment are covered in Module 9.

Every CI system, regardless of which tool you use (GitHub Actions, Jenkins, CircleCI, GitLab CI), follows the same loop:

If any step returns a non-zero exit code, the pipeline fails and reports the failure. No code that fails CI can be merged into the protected main branch — this is the quality gate.

The cost of slow feedback

The value of CI is in the speed of the feedback. Consider:

An automated test is a program that calls your code with specific inputs and verifies the outputs match expectations. The Arrange-Act-Assert pattern gives every test a consistent structure:

def
 test_calculate_discount
():
    # ARRANGE: set up inputs and expected values
    price = 100.0
    discount_rate = 0.20
    expected = 80.0

    # ACT: call the code under test
    result = 
calculate_discount
(price, discount_rate)

    # ASSERT: verify the result
    assert
 result == expected

The assert statement raises an AssertionError if the condition is false. pytest catches this and marks the test as failed.

Testing edge cases

Testing only the happy path (expected input, expected output) is insufficient. Good tests also cover:

• Boundary values — what happens with the smallest or largest valid input?
• Empty input — what happens with an empty list, empty string, or zero?
• Invalid input — does the function handle wrong types or values gracefully?
• Error conditions — does the function raise the right exception when it should?

import
 pytest

def
 test_divide_by_zero
():
    # Verify the function raises ValueError for division by zero
    with
 pytest.raises(ValueError):
        
divide
(10, 0)

def
 test_empty_list_returns_none
():
    result = 
find_max
([])
    assert
 result is None

def
 test_single_element_list
():
    result = 
find_max
([42])
    assert
 result == 42

Not all tests are equal. The testing pyramid describes three layers of automated tests, with different trade-offs of speed, scope, and cost.

           /\
          /  \
         / E2E\  ← few, slow, expensive
        /------\
       /Integr. \  ← some, medium
      /----------\
     /    Unit    \  ← many, fast, cheap
    /______________\

For this module, we focus on unit tests. They run in milliseconds, require no infrastructure, and give precise feedback on exactly which function is broken.

pytest is Python's most popular testing library. It discovers tests automatically: any file matching test_*.py or *_test.py, and any function or method starting with test_.

# Run all tests
pytest

# Run tests in a specific file
pytest tests/test_auth.py

# Run a specific test by name
pytest tests/test_auth.py::test_login_success

# Verbose output — show each test name
pytest -v

# Stop after first failure
pytest -x

# Show local variables on failure
pytest -l

# Run tests matching a keyword
pytest -k "login or logout"

========================= test session starts ==========================
collected 5 items

tests/test_auth.py::test_login_success PASSED              [ 20%]
tests/test_auth.py::test_login_wrong_password PASSED       [ 40%]
tests/test_auth.py::test_login_empty_username PASSED       [ 60%]
tests/test_auth.py::test_logout PASSED                     [ 80%]
tests/test_auth.py::test_session_expires PASSED            [100%]

========================== 5 passed in 0.23s ==========================

FAILED tests/test_auth.py::test_login_wrong_password

========================= FAILURES =================================
_____________________ test_login_wrong_password ____________________

    def test_login_wrong_password():
        result = login('alice', 'wrong')
>       assert result == False
E       AssertionError: assert True == False
E       (login returned True but should have returned False)

tests/test_auth.py:24: AssertionError

Many tests need the same setup — a database connection, a configured application, a sample user. Copying this setup into every test function is repetitive. pytest fixtures solve this:

import
 pytest

# Define a fixture
@pytest.fixture
def
 sample_user
():
    return
 {        'username'
: 'alice'
,        'email'
: 'alice@example.com'
    }

# Use the fixture as a parameter
def
 test_create_greeting
(sample_user):
    result = 
create_greeting
(sample_user)
    assert 'alice'
 in result

def
 test_user_has_email
(sample_user):
    assert '@'
 in sample_user['email'
]

A CI log can be hundreds of lines. Finding the failure quickly is a critical skill. Follow this process:

1. Find the step that failed — pipeline tools highlight failed steps in red. Click it to expand.
2. Scroll to the first error — not the last. The first error often causes the subsequent errors.
3. Identify the type of failure — is it a syntax error? An import error? A test assertion failure? An environment error?
4. Note the file and line number — always shown for Python errors.
5. Reproduce locally — run the exact same command the pipeline ran.

A quality gate is a rule the pipeline enforces: code that fails the check cannot be merged. Common quality gates include:

• All tests must pass
• Code style must conform (e.g. flake8, black --check)
• No known security vulnerabilities in dependencies
• Test coverage does not drop below a threshold (e.g. 80%)
• No secrets or credentials in the code

Quality gates are enforced by configuring GitHub branch protection rules: a branch can require all CI checks to pass before a PR can be merged.