I want to learn (and master) TDD. What are the best:
- list of exercises
- personal words of wisdom
for learning, appreciating, and using TDD?
closed as not constructive by ChrisF♦ Feb 14 '12 at 8:41
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
Personally I found that reading a JUnit essay or two emphasizing that "you write the test before the code" was enough to get me started.
The most important part in learning this technology is to write a LOT of test-based code, because you need to change some of the most basic ways you think of writing code. Things like:
The best place to start small, is with your utility routines. Next time you need one then just design that with tests first, write a lot of tests covering all your official usecases (including what should happen with null values passed etc), and when all the use-cases are implemented you should be able to use it directly in your code, and be confident it works as expected.
It is also my experience that good tests can do additional work as documentation, because you have a lot of very concise code saying exactly how the code behaves in various situations, which can be easily proved to be correct (green bar). With careful comments you don't get it much better than that.
For Java jUnit version 4 is really nice.
Apart from some of the books already mentioned, I can recommend Growing Object-Oriented Software Guided by Tests. I haven't finished reading it yet, but it is a worthy read, including the story of a whole, lifelike TDD project, not just simplified code examples.
In my opinion, TDD is more about making the code testable, than writing tests.
Sure you can write a test before coding, but the whole reason the test is written is so you can code -- which won't stop you from writing code that's hard to test.
Take a look at this to get a better sense of what I mean: My Unified Theory of Bugs
If you're interested in the concept, and want to learn more, just comment -- and I'll point you in the direction of a recorded presentation on the topic from Google.
I've read two books:
Test Driven Development: By Example by Kent Beck and
Unit Test Frameworks by Paul Hamil
The Beck book is well regarded, but I didn't get started with unit testing until I read "Unit Test Frameworks". I do some TDD, but I also add tests to older code that I have to maintain (when I can).
Edit: Also, once you get a handle on it, I recommend using it on a current project right away. For me that's when the real learning occurred, and I think the "Unit Test Framework" book was a better reference book for this purpose. (I was using nunit with C#).
While not primarily about TDD (though it does touch on it, as well as designing for testability), The Art of Unit Testing is a book I would recommend because it teaches you how to write good tests.
More specifically, it teaches how to create trustworthy, maintainable, and readable tests. I think this is the most important section of the book, outside of perhaps the basics about unit testing and isolation frameworks. It's obvious that if unit tests become a pain point or add friction to a developer's job, then any success or benefit from them will be limited. If one invests the time and effort to create the tests, then (s)he should be able to get the most return out of that investment.