These two comments (below) seem to be in opposition to one another. It's clear to me what my code needs to do (Above) How do I even know what correct outputs

These two comments (below) seem to be in opposition to one another. It's clear to me what my code needs to do (Above) How do I even know what correct outputs to code interacting with those components would be? (From your original comment) If you know all the possible environmental factors that you need to deal with, then you can write up front tests for them (whether that is economical or not, is a different question). However, if the complete set of environmental factors is unknown (though potentially discoverable) then you have a requirements problem, not a code problem. TDD can't solve that problem (although it might help make it obvious that the problem exists). TDD is based on the assumption that it is possible to know when your code "works", and requires you to define that criteria up front. But any development process you follow is must have some way of answering the "am I done yet?" question, or you'd never ship anything. Perhaps your concern is that TDD doesn't help solve the "I don't have a complete set of requirements" problem. If so, then that's true, but it never claims to. If you don't have the requirements yet, then TDD says you're not ready to write code, and some other process has to be followed in order to produce requirements. It is possible to do TDD if you only have some (but not all) requirements - but you can only write code for the requirements you do have.