If you’ve never done Test Driven Development or aren’t even sure what this "crazy TDD stuff” is all about than this is the series for you. Over the next 30 days this series of posts take you from “I can spell TDD” to being able to consider yourself a “functional” TDD developer. Of course TDD is a very deep topic and truly mastering it will take quite a bit of time, but the rewards are well worth it. Along the way I’ll be showing you how tools like JustCode and JustMock can help you in your practice of TDD.
Previous Posts in this Series: 30 Days of TDD – Day 29 – Reader Question #5
I hope you’ve enjoyed this series and have found the information in it helpful in your development as a practitioner of Test Driven Development. This series may be over, but that doesn’t mean this is the last post about TDD that you’ll see on this blog. As time goes by I’ll be publishing posts to help bolster your TDD knowledge and keep your practice of TDD going.
Some Parting Thoughts and Advice
Remember that TDD, just like any other concept or practice in software development takes practice. The more you use TDD the easier TDD becomes. It’s easy to get discouraged at first, but the rewards of pushing forward and putting in the work to really lean and understand TDD are the same things that are going to make you a better developer. If you feel like you are hitting a “dead end” don’t just give up. Talk to other developers, look for others who have had a similar situation (and how they solved it) or simply take a break. A solution may not come to you instantly, but it will come to you.
Remember to keep your tests simple. Tests that are simple drive software that is simple, easy to understand and easy to maintain. Make sure your test only tests one thing and remember the simplest test is usually the best one. The goal of TDD is not to write a lot of complex code; it’s to write code and API’s that are easy to work with and maintain. If you find that your tests are becoming very long, complex and difficult to manage take a step back and look at them. Are they focused on more than one thing? Are you over-mocking? Is the unit of work you’re trying to test too complex? If the answer to any of these is “yes” then don’t be afraid to refactor your code, your tests or both.
If you are in a situation where you are working on a large brown-field project, it might be difficult to introduce TDD for both technical and non-technical reasons. In regards to the technical issues, it’s important recognize that you are not going convert the project or your team to TDD overnight, and that’s OK. As you work on the application write tests where you can and refactor where it makes sense. Over time the quality of the existing code will increase and your team members will see the value of unit testing. When addressing the non-technical reasons remember that time and money are powerful forces in software development. If you can show that the practice of TDD saves both you’ll start to gain allies in your fight. If possible try to get management to agree to a small, low risk piloting of TDD. If you can show that value on a small project you’ll have an easier time getting buy-in on a lager one.
Tools like JustCode, JustMock, NUnit and Ninject are important frameworks that help enable the practice of TDD. But remember that TDD is a practice and philosophy that transcends tools. Becoming proficient in the tools and frameworks you’ll be using is important, and your skill with them will inspire confidence in developers you are trying to get on the TDD bandwagon. But the tools shouldn’t be the center of your discussion. Be sure to give equal time to the ideas of “test first”, SOLID, Dependency Injection and the concept of writing the simplest code possible to make your tests pass.
Thanks for reading!