Chapter 6: To infinity and beyond
After doing this course's exercises, you should have gotten over the initial hurdle of learning TDD, and have some idea of what TDD-done-well should look like. You'll likely have lots of room for improvement: trying to implement too much in one go, test names which are not very descriptive, test code which is tightly coupled with implementation details, complex test setups, untestable code, duplication which has gone unnoticed and so on. But a bad test is better than no test, and the first step to improvement is awareness.
It should take something like 200 hours of practice to reach moderate competence with TDD. For the first year, focus on giving good names to your tests. Write lots of little applications which push you to solve different kinds of problems, whether they are code katas or real applications. Avoid things that make testing hard (e.g. database, user interface), so that you can focus on just improving test readability.
After the first year of practicing TDD, writing tests first should be natural to you, and you should have seen how easy it is to work in well-tested codebases. The next challenge will be learning to write testable code. This will take more than 10 years¹ - even a lifetime. Tackle problems which others say can't be tested, and figure out how to test them. Explore designs which make testing them easier. Start a project and then leave it for a couple of years for others to maintain - then come back to see how your original designs survived the test of time. Learn and repeat. Join legacy code projects and transform them to be as easy to work with as greenfield projects.
Join communities of like-minded people. For example the SoCraTes (Software Craft and Testing) open space unconferences are held around the world and are filled with people who are passionate about the craft, including TDD. SoCraTes Germany is the oldest and biggest, and of particular mention is the chilled-out Codefreeze in Northern Finland.
Here are a few books that every software developer should read:
Test-Driven Development: By Example (Kent Beck, 2002)
Covers everything there is to know about TDD, except mock objects.
Growing Object-Oriented Software, Guided by Tests (Steve Freeman, Nat Pryce, 2009)
Covers everything there is to know about mock objects. Actually the book is about message passing based object-oriented programming.
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin, 2008)
About writing good code.
Understanding the Four Rules of Simple Design (Corey Haines, 2014)
About removing duplication and improving names.
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Jez Humble, David Farley, 2010)
Describes one fundamental practice of modern software development.
For a more higher level book about software development process, Extreme Programming Explained: Embrace Change (Kent Beck, 1999/2004) is still as timely as ever. The Art of Agile Development (James Shore et al, 2007/2021) and Modern Software Engineering (David Farley, 2021) should be good as well, covering also some things learned more recently.