So what is TDD?
Can you actually write a test before writing a single line of implementation logic? How do you know what method, class, or interface will contain the method under test? Sounds a bit odd… That’s exactly how I felt when I first read about TDD.
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.
But once I got the hang of it I realised, that’s the whole point! It guides you through the design.
TDD concept was introduced or developed by Kent Beck and in his book Test Driven Development: By Example he explains the pains of traditional development process and how adopting test driven development helps. And also the foundation and key concepts are explained with lots of code samples.
LETS TEST THE WATERS WITH A HELLO WORLD IN TDD
All that is great! But how do you practice TDD in Java development? Well, I started by applying it to a ‘hello world’. Too trivial, I know, but I like it to be as simple as possible.
Requirement: I want to print ‘hello world’
1 | Writing the test
We think of the outcome first, and write an assert to test if we get what we want. In this case, we want the string ‘hello world’.
2 | Writing the minimum code in order to pass the test
3 | Refactor both the test and the implementation
It’s that simple. So what’s keeping you from practicing TDD? Let’s get started.
For the majority of us who are so used to writing the method or function first and writing the unit tests later or may be skipping it altogether, it may feel like swimming upstream, but like anything, a bit of practice will make it a lot easier and natural.
Following are a few things that motivated me and planted the foundation of TDD in myself.
- Test Driven Development: By Example” by Kent Beck - Reading this book, set my mind up for it and it really extracts the essence of test driven development.
- Writing great unit tests i.e. simple, understandable, and maintainable unit tests.
- TDD Kata - Small practice exercises that help you master it.
Yes, the quality of unit tests does matter as much as the quality of production code.
Why it’s so important to write good unit tests?
If unit tests lack quality (i.e. if the tests are not easily understandable by a person other than the one who wrote it, or if they inter depend on other tests causing multiple tests to fail if one test is broken, or if unit test suit take ages to run, or etc…) maintaining those unit tests would become a nightmare in the long run and would ultimately lead to ignoring all the tests one by one as they fail. Don’t believe me? Then you may want to read this open letter from an ignored test
Some qualities of a great unit test
- Each unit test should be able to run independent of other tests.
- Each test should test just one thing (single behavior, method, or function)
- All external dependencies should be mocked.
- The assumptions for each test should be clear and defined within the test method.
- name of the test method should be meaningful.
- Unit tests should be fast, so that it could be run as often as required.
TDD KATA - PRACTICE MAKES PERFECT
Like anything, the key to TDD is practice. But how do you practice? TDD KATAs to the rescue.
KATA has it’s roots in Japan, and it means a detailed or defined set of movements to be practiced over and over again. Hope it makes sense :)
TDD Kata is a tiny bit of coding that you could repeat over and over again, not a new one every day but the same coding exercise until you get sick of it. So, head over to this repository where you can find a list of Katas to practice and start now.
Please leave a comment and let me know if you liked it!