As for myself: I am not sure that TDD can really be learned effectively from a book alone. I read Kent Beck's book and my reaction was "well this is concisely-stated bullshit". Then I went to work for Pivotal Labs and I now I understand the fuss.
My problem is that Uncle Bob's dogmatism, is then cargo culted by mostly 'weak' developers as a shield behind which to create an illusion of competence.
Just repeat outrageous things like everything must be TDD, we must have 100% code coverage, and avoid those tricky decisions called software engineering.
But then a lot of business-logic software is out there just to support client-A able to do rpc calls to your service, and usually one or two engineers implement it, few more look at it, gets deployed, and it's expected to run flawlessly for long time.
Then someone else modifies it later, and the original "developers" are gone (another project, company, retired, etc.)... Definitely not the case with Linux.
So my take is that such software needs TDD to hold on it's own, such that it could be developed further by complete strangers.
My current plan is to finish reading and working through the examples in 'Growing Object Oriented Software, Guided by Tests' as that seems to be a very highly recommended book.