Link Details

No, we're not. TDD requires that you write your tests upfront as a method of _design_, thus checking your code against a myriad number of tests to prevent accidental breakage against edge cases, and expected use-cases.

Yes, the real benefit of TDD comes when you do it from the get go. But "upfront" is a relative term. TDD is a continuous process that drives design and development throughout the life cycle. However, on most projects the test cases don't start to drive things until late in the cycle. Even so, that actual behavior is the same, we learn from our test cases and react! So my point is that once we realize that we already know how to go through the TDD movements then maybe it will be easier to just start doing them at the beginning of the life cycle.
,

Here is another clarification. You might not "officially" be doing TDD, but once you do start testing your tests start to show you where the gaps are in your understanding of the functionality that you are trying to implement. At this point the tests are driving your development. And we are really good at fixing things once we understand the problem. So, you can officially start doing TDD by just moving this behavior (that we do so well) to the beginning of the life cycle.

The code quality when the test is made upfront tend to be of more quality then it is when it was delayed later, which I guess, what made the distinction of TDD.

If its late in the cycle, you can say from the point onward, that it is test driven. But that does not apply to the development that has been done to that point, which is not test driven.

Anyway, I guess the point of the article is more of giving a different point of view to those who are still new to TDD, to look in a way that is easier to start.

Yes, the goal is to take the activities that you are 'already' doing late in the cycle and move them upfront where they can be more affective. And this move isn't too daunting because you are already going through some of the motions.
,