How to get started with TDD?

Many programmers use code reviews to ascertain that software functionality has been developed correctly, code has followed the standards agreed by the team, and the software design can support to meet the future customer needs. Another means of achieving this goal is test-driven development (TDD).

In TDD approach of software development, the idea is to repeatedly take tiny, safe steps, each of which results in adding or changing a micro-behavior. The TDD cycle, repeated over and over, is conceptually simple. You start a step by writing a failed test that specifies the desired behavior. Only then do you make the code changes needed to make the test pass, and then you refactor the code to clean up the design.

A test written in TDD should have clear intention (behavior), should be fast because if tests run slow, you may not want them to run frequently. If you don't run them frequently, you won't find problems early enough to fix them easily. You won't find early opportunities to refactor your code and eventually the code will begin to rot. It should not be depend on other tests, all its dependencies should be mocked, and be able to run independently. It should be able to run in any environment (e.g. QA, stage) and result should have Boolean output to understand the test is passed or failed. A developer shouldn't be analyzing the logs to understand whether the tests pass.

TDD allows programmers to focus on "What" (to achieve) before "How" (to implement). A programmer in a test first approach need to know the behavior to be tested and then work on implementing that behavior. TDD as a skill, its learning curve is steep. It is particularly challenging to execute in legacy code bases. Still, it’s an established practice, so you might be wondering:

How do we get started with TDD?

As a first step one need to get educated with TDD and practice. Learning the TDD theory doesn't takes much time, but developing the skill to write test-driven code takes a significant amount of time. I coached many teams on TDD where people do coding, exercising, mocking dependencies, and so on — and even then they need guidance and hand holding to get started on their own real code. This is bit hard and requires a lot of practice and mindset.

A good way to practice TDD is using TDD katas. Kata has its roots in Japan, and it means a detailed or defined set of movements to be practiced over and over again. TDD kata is a tiny bit of coding that you could repeat over and over again.

You must start with the easy cases, as they will be hard enough. Only after getting the rhythm with the simple cases should you look at test-driving dependencies and mocking them. Mocks are cool and powerful — but also dangerous and confusing. Playing with them is the last thing you should do!

When working on a legacy code, trying to implement ideal TDD is not going to work. The code you're inheriting wasn't built with testability in mind, the original author may no longer be on the team or even in the organization, the dependent libraries may have changed, and so on. So, by applying TDD to the new code you're writing, i.e. changes in the existing code, you minimize the risk and don't increase the technical debt.

TDD’s rapid cycles require a suitable technical environment. Programmers intending to test-drive code in some module or layer must be able to compile it really, really quickly. They can’t wait 15 minutes for a build; that’s too long. They should be able to quickly compile the relevant portions locally. If the team uses Eclipse, IntelliJ, Visual Studio, or other modern environments, that’s usually a given.

Since the introduction of TDD spells a big change, three critical conditions must be fulfilled. One is motivation, another is bandwidth, and the third is focus. If you’re under schedule pressure, or if your developers don’t care much for TDD because they think they’re doing fine, then you are probably not going to succeed with it. The team must be willing, ready, and able for TDD to stick.

Since TDD is for every programmer on the team, they could learn it together. Whether using pair programming, a buddy system, or study groups, people don’t need to struggle with it alone. Programmers may be sensitive about looking bad during the initial stages of new learning; this stress is reduced by having everyone in the same boat and lending each other a hand. Make TDD adoption a team endeavor, not something that everyone does on their own time.

Please do share your thoughts and feedback!