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.

5 Answers
5

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:

Writing the test before the code, makes you think up front of how you will invoke your code and get the result back. This means you design the API first based on how you will use it. This frequently results in a better API.

Your coding style will change because you will NEED to think more modular, to be able to test parts of the code instead of just the whole thing.

You will also get to a point where you will be able to confidently pull out a major chunk and insert a new chunk instead behaving the same, because your test pass. I did that recently with a date parsing library, as the original was too lenient.

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.

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.

I think this is my favorite book and the one that affected the way I work the most, not only about TDD but about Software Dev in general. I also have to admit that I didn't read many TDD books so perhaps don't trust me that much.
– antonio.fornieDec 4 '17 at 10:01

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.