> I don't think I've written any production code in years where I gave up because it was intrinsically not possible.
What I meant by "not possible" is writing both sides of the API at the same time. For example, you write a library for overlaying maps on video feeds, it is good if you are also writing the application that uses it. For example a drone controller. So in the early phase, you write the library specifically for your drone controller, changing the API as needed.
But sometimes, the drone controller will be made by another company, or it may be a project too big not to split up, that's the "not possible" part. And without a clear, in control use case, you have to make guesses, and writing tests can help make good guesses.
>What I meant by "not possible" is writing both sides of the API at the same time. For example, you write a library for overlaying maps on video feeds
If I were doing this I would probably start by writing a test that takes an example video and example map and a snippet of code that overlays one on to the other and then checks the video at the end against a snapshot.
>But sometimes, the drone controller will be made by another company, or it may be a project too big not to split up, that's the "not possible" part. And without a clear, in control use case, you have to make guesses, and writing tests can help make good guesses.
This is the figuring out the requirements part. If you are writing an API for another piece of software to call you might have to do some investigation to see what kind of API endpoint it expects to call.
What I meant by "not possible" is writing both sides of the API at the same time. For example, you write a library for overlaying maps on video feeds, it is good if you are also writing the application that uses it. For example a drone controller. So in the early phase, you write the library specifically for your drone controller, changing the API as needed.
But sometimes, the drone controller will be made by another company, or it may be a project too big not to split up, that's the "not possible" part. And without a clear, in control use case, you have to make guesses, and writing tests can help make good guesses.