Test Driven Development in Python: Independent and AI Co-Authored Testing

Table of Contents

1. Challenge

   Explore the Starting Point

   Introduction

   Skipping tests is easy under deadline pressure, until a change silently breaks something a test would have caught. In this lab you practice test-driven development in Python: you write a failing test first, build the minimum code to pass it, and refactor with confidence that nothing's broken.

   You're extending a small stock-management module for a warehouse system. It has stated requirements and no tests yet. You start by writing your own tests directly from those requirements. Later in the lab, you put an AI assistant to work generating a test suite of its own, then compare it side by side against a suite you wrote independently, deciding what to keep, fix, or discard.

   By the end, you'll have practiced the Red-Green-Refactor cycle by hand three times, and you'll have direct, first-hand evidence of where AI-generated tests help and where they mislead.

   Task 1: Explore the Starting Point

   Before you write a single test, get oriented. You're going to work from requirements-spec.md, a plain-language specification for four functions in app/inventory_service.py. None of them are implemented yet, and no tests exist yet. That's the correct starting state: this lab is deliberately starting from zero, not from a codebase you need to reverse-engineer.

   Your Task

   1. Open requirements-spec.md and read all four sections.
   2. Open app/inventory_service.py and compare its function signatures and docstrings against what you just read.
   3. Open tests/test_stock_operations.py, tests/test_low_stock_independent.py, and tests/test_low_stock_ai.py and note that they import the module but define no tests of your own yet.
   4. Run the test suite from your terminal with pytest.
   5. Confirm that you see a message that no tests ran.

   Outcome

   • Running the test suite collects successfully, with no collection errors.
   • There are no failures.
   • You can describe, in your own words, what each of add_stock, reserve_stock, release_reservation, and low_stock_items is supposed to do before you write a single test.

   This starting point is your baseline. From here, every test you add should fail for a reason you predicted, before you make it pass.

   info> If you get stuck, you can refer to the provided solution code for each task, available in the solution folder.

2. Challenge

   Write Failing Tests First

   You now understand what add_stock and reserve_stock are supposed to do but neither has a single test proving it. In this step, you write those tests before writing any implementation, working only from requirements-spec.md.

   This is the "Red" phase of Red-Green-Refactor: a test that fails for the right reason is just as valuable as one that passes. Writing it first forces you to pin down exactly what "correct" means, in terms you can check automatically, before you're tempted to just start coding and see how it goes.

   When you're done, running the test suite should show new tests, and every one of them should fail, because add_stock and reserve_stock still raise NotImplementedError.

3. Challenge

   Make the Tests Pass, Then Refactor

   You have six failing tests describing exactly what add_stock and reserve_stock must do. Now write the simplest code that makes them pass — don't reach for elegance yet, just green. Once every test passes, you'll have a safety net, and only then do you clean the implementation up.

   There's also a second suite you haven't seen the contents of, test_acceptance_stock_operations.py, checking the same two functions directly against the written requirements. It exists to catch anything your own tests didn't think to check. Passing your own tests isn't the finish line here — passing both is.

4. Challenge

   Repeat the Cycle for release_reservation

   One pass through Red-Green-Refactor doesn't make it a habit — repetition does. In this step you go through the whole cycle again, this time for release_reservation: write the failing tests from requirements-spec.md, section 3, implement the minimum code to pass them, then refactor.

   You'll notice this function is close in shape to reserve_stock. Resist copying its tests wholesale — release_reservation has its own requirement, and the point of this step is to check it against that requirement, not against a sibling function.

5. Challenge

   Write Your Own Tests for low_stock_items

   You're about to add a fourth function, low_stock_items, and this time an AI assistant is going to write a test suite for it too. Before that happens, write your own suite first, from requirements-spec.md, section 4, with no AI involvement at all.

   This isn't busywork: it's your baseline. In the next step you'll put an AI-generated suite for the same function directly alongside this one, and the only way to judge what the AI got right or wrong is to already have your own considered answer to compare it against.

6. Challenge

   Generate, Compare and Decide

   Now bring an AI assistant into the loop. You'll prompt it to write a test suite for low_stock_items from the same requirement you just tested independently, then put the two suites side by side. An AI-generated test suite can look complete and still miss an edge case, assert the wrong value, or test something the requirement never asked for — the only way to know which is to compare it against a suite you already trust.

   By the end of this step you'll have decided, test by test, what to keep, what to fix, and what to throw out — and an implementation that satisfies whatever you decided was actually correct.