I love the efforts to build these types of resources, I just hope this isn't redundant with Michael Hartl's tutorial.
Also, I'm not a believer in TDD, especially with beginners. I find it tedious especially when prototyping an app, which I almost always do before starting a non-trivial project. Once my prototype works reasonably well, I do a refactor with good test coverage in an effort to produce production ready code.
As someone who learned ruby first and then went through Hartl's tutorial I have to agree 100%. I wanted to learn about the framework. All the TDD stuff complicated the process and really slowed me down. I ended up skipping over all the TDD stuff and was able to really get a lot out of it. I fully intend to go back through the tutorial soon to pick up the TDD elements.
While I have become a proponent of TDD and have come to appreciate it in larger projects, I agree and remember the tediousness of it as a beginner.. It is good to inform the beginner of its style and merits, but not to enforce it -- rather let them decide for themselves if it helps them and their team in the long-run; experience is a far superior teacher
I think that as long as the code you commit has full coverage and good quality tests (not only tests to improver coverage) then testing your code after writing it can be equally effective in large projects.
I guide many junior developers and find that TDD is just too much to enforce while learning.
I'm not sure this series could be redundant as it's free and Michael's videos cost money. Michael's website also looks like one of those classic 2001 sales pitch/squeeze page which makes me doubt the quality of the tutorials.
Worse yet, the TDD in that tutorial didn't even use the standard test framework built into Rails - so you're taught from the start to use something non-standard. So irritating.
I always recommend the Pragmatic Programmers book for new learners.
Also, I'm not a believer in TDD, especially with beginners. I find it tedious especially when prototyping an app, which I almost always do before starting a non-trivial project. Once my prototype works reasonably well, I do a refactor with good test coverage in an effort to produce production ready code.
I'm a huge believer in testing, just not TDD.