Depending on the size or nature of the unknowns, you might need to do SPIKEs or POCs (eventually before you even start coding), which may benefit from a test harness for their evaluations (for example to ensure reproducibility), but the quality requirements against these experimentations will be very different from code which is supposed to go into the main line of the product.
“ Red: Start with tests focusing on the main and edge cases.
Green: We write the sorting function to make the tests green.”
Sounds like you’re writing multiple tests before making any pass. While this doesn’t seem like a bad workflow it’s not TDD. Following TDD you’d write one test, make it pass, then write the next test.
Your point about evolving APIs is well taken. By only writing one test at a time you reduce the amount of work retrofitting new APIs.
I agree with you Teiva, especially about the point in API that is still changing while you code. I had tried TDD and I would say that it depends on the changes we are making. Like any tool / methodology, figure out if it’s a good fit before blindly apply it to your current situation.
> Often, there are too many unknowns, like which data sources to use or which external APIs or services I need to rely on.
In my interpretation of TDD (mostly drived from https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 :-) ), it is about helping you grow the code: it helps you resolve the unknowns (1) step-by-step (2) based on requirements (3) with an easy-to-test (hence high-quality) code structure.
Depending on the size or nature of the unknowns, you might need to do SPIKEs or POCs (eventually before you even start coding), which may benefit from a test harness for their evaluations (for example to ensure reproducibility), but the quality requirements against these experimentations will be very different from code which is supposed to go into the main line of the product.
I messed up the link to this excellent book (and, despite the apparently functional "Edit" menu-item associated with my comment, I am unable to edit my comment); correctly: https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627
“ Red: Start with tests focusing on the main and edge cases.
Green: We write the sorting function to make the tests green.”
Sounds like you’re writing multiple tests before making any pass. While this doesn’t seem like a bad workflow it’s not TDD. Following TDD you’d write one test, make it pass, then write the next test.
Your point about evolving APIs is well taken. By only writing one test at a time you reduce the amount of work retrofitting new APIs.
I agree with you Teiva, especially about the point in API that is still changing while you code. I had tried TDD and I would say that it depends on the changes we are making. Like any tool / methodology, figure out if it’s a good fit before blindly apply it to your current situation.