Read the Result and Test One Story

The first dot was useful because pytest collected one function. A summary can also tell you why there is not yet trustworthy green evidence.

The site runtime already includes the course’s pinned pytest. From this lesson onward, python -m pytest uses that runtime, so losing the disposable .venv does not block the site exercises. On your own machine, keep using your project environment’s Python with -m pytest.

Run the suite and then ask Bash for the process status:

python -m pytest -q
echo $?

Read the outcome before editing production:

Status 2 is not a failed expectation. Repair the collection/import problem first. Status 5 is not success either: no test observed production behavior.

Let one test tell one story

Open the test module and expand the equality example:

nano tests/test_catalog.py

Keep three visible movements:

def test_equal_quantity_is_included():
    # Arrange
    item = {"sku": "EQ-4", "quantity": 4}
    items = [item]

    # Act
    selected = select_items(items, 4)

    # Assert
    assert selected == [item]

Arrange creates the input and expectation boundary. Act exercises one public behavior. Assert compares the observable result. The comments are temporary signposts, not magic syntax; the separation keeps a future failure from mixing three possible causes on one line.

Run pytest again. If it reports a test failure, start at the assertion’s expected and actual values, then inspect the innermost relevant project frame. Do not “repair” collection by renaming the function so it disappears.

The equality case is green. The same inclusive rule has neighboring cases; next you will express them without copying the whole function three times.

If pytest reports something you cannot interpret, paste the whole summary to Monty and ask what the status code means before you change any code. Repairing the wrong layer wastes more time than reading the message.