What do I mean by all of this? Well, let's take some examples to make it clearer. When doing TDD, the cycle looks like this:
See a problem (observation).
Decide to solve the problem (decision).
Write a test (action).
Look at the test and see if the API looks good (observation).
If it doesn't look good, decide how to fix it (decision), change the test (action), and repeat Observation → Decision → Action until you like what the API looks like.
Now that the API looks good, run the test and see that it fails (observation).
Decide how you're going to make the test pass (decision).
Write some code (action).
Run the test and see that it passes or fails (observation).
If it fails, decide how to fix it (decision) and write some code (action) until the test passes (observation).
Decide what to work on next, based on principles of software design, knowledge of the problem, or the data you gained while writing the previous code (decision).
And so on.
There are many valid processes of course. For...