Test-driven development (TDD) is a practice of writing a test before the code it requires, then letting that test guide a short implementation cycle. It emphasizes software that is easy to test and gives developers early questions to answer: what needs testing, how it will be tested, and how others will understand it. This is especially useful when verifying generated code or business-rule-heavy payment processing. section 2.3.3 section 2.4
A practical TDD cycle is:
- Start with a small, observable behavior, such as reading every line in an ACH file or retrieving batches for a file. section 2.4 section 7.4.1
- Write the test before the supporting behavior exists; an initial failure is expected and identifies the missing work. section 8.4 section 7.4.1
- Add the smallest focused implementation that makes the test pass, then continue toward the fuller feature. section 7.4.1 section 8.4
- Extend and review tests as the application grows, including whether they remain reliable in a CI/CD release pipeline. section 12.2.4
Building an API endpoint from a test
A test requests a batches endpoint for an ACH file and asserts a 200 status. Before the endpoint exists, the request returns 404. Define a minimal endpoint that returns a hardcoded response, rerun the test, then replace that placeholder with a focused get_batches call and a response model tied to the batch-record data. section 7.4.1
TDD need not be followed rigidly to be valuable. Mixing tests and coding in small, fast feedback cycles still improves confidence in both hand-written and AI-generated code. Unit tests are the main mechanism here; BDD-style syntax can also describe API behavior. section 2.4 section 2.3.3 section 7.4.1
Listing 7.15 Test class for the /files/id/batches
class TestAchBatchesApi:
client: TestClient = TestClient(app) #1
ach_files_id: Optional[str] = None #1
def setup_method(self, method: Callable) -> None:
ach_file = "../data/sample.ach" #2
SqlUtils.truncate_all() #2
self.ach_files_id = SqlUtils.create_ach_file_record( #2
ach_file, str(randint(1, 99999999)) #2
) #2
AchFileProcessor().parse(self.ach_files_id, #2
➥ "data/sample.ach") #2
#2
def test_get_batches_api(self): #3
response = self.client.get("/api/v1/files/{self. #3
➥ach_files_id}/batches") #3
assert response.status_code == 200, #3
➥ response.text #3
#3
def teardown_method(self, method: Callable)#4
➥ -> None: #4
print(f"\nTeardown for {method.__name__} #4
➥ test method execution") #4
The test class makes the intended API behavior concrete: it prepares parsed ACH data, requests the batches route, and checks for a successful response before the endpoint implementation is expanded. section 7.4.1
