What you are describing as a workflow isn't in my opinion the Spirit of TDD.
The synopsis of Kent Becks book on Amazon says:
Quite simply, test-driven development is meant to eliminate fear in
application development. While some fear is healthy (often viewed as a
conscience that tells programmers to "be careful!"), the author
believes that byproducts of fear include tentative, grumpy, and
uncommunicative programmers who are unable to absorb constructive
criticism. When programming teams buy into TDD, they immediately see
positive results. They eliminate the fear involved in their jobs, and
are better equipped to tackle the difficult challenges that face them.
TDD eliminates tentative traits, it teaches programmers to
communicate, and it encourages team members to seek out criticism
However, even the author admits that grumpiness must be worked out
individually! In short, the premise behind TDD is that code should be
continually tested and refactored.
Practical TDD
Formal automated Testing, especially Unit Testing every method of every class is just as bad an anti-pattern and not testing anything. There is a balance to be had. Are you writing unit tests for every setXXX/getXXX
method, they are methods as well!
Also Tests can help save time and money, but don't forget that they cost time and money to develop and they are code, so they cost time and money to maintain. If they atrophy from lack of maintenance then they become a liability more than a benefit.
Like everything like this, there is a balance which can't be defined by anyone but yourself. Any dogma either way is probably more wrong that correct.
A good metric is code that is critical to the business logic and subject to frequent modification based on changing requirements. Those things needs formal tests that are automated, that would be a big return on investment.
You are going to be very hard pressed to find many professional shops that work this way either. It just doesn't make business sense to spend money testing things that will for all practical purposes never change after a simple smoke test is preformed. Writing formal automated unit tests for .getXXX/.setXXX
methods is a prime example of this, complete waste of time.
It is now two decades since it was pointed out that program testing
may convincingly demonstrate the presence of bugs, but can never
demonstrate their absence. After quoting this well-publicized remark
devoutly, the software engineer returns to the order of the day and
continues to refine his testing strategies, just like the alchemist of
yore, who continued to refine his chrysocosmic purifications.
-- Edsger W. Djikstra. (Written in 1988, so it's now closer to
4.5 decades.)
See also this answer.