“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function.”
–Robert C Martin (Author: Agile Software Development, Principles, Patterns, and Practices)

What is Test Driven Development/Design?
Test driven development is not about testing; it’s a technique that teaches you to think about the code. The unit tests we get in the end are just useful side effects. In simple terms, it is defined in the red-green-refactor terms.

Red – Green – Refactoring:

  • Red – Create a failing test
  • Green – Write enough code to make the test pass
  • Refactor – Clean up code and test

Advantages:

  • Gets detailed specifications
  • Quick feedback
  • Saves time (waterfall methodology takes weeks to test after implementation)
  • Organized and neat code
  • Ensures that changes don’t break the expectations from the code

DEMO
Imagine we are developing a music analysis and suggestion app. All it does is to get information and give suggestions related to the queried artist. A sample Java gradle project is used for quick demo using JUnit on intelliJ IDE. The following example we won’t run through whole app development but just a single step.

Step one:

  • Let’s begin with creating a test using JUnit. Right click on the package you want to write the test New | Java Class
  • Name the class as MusicAnalyserTest; we don’t necessarily have any development code yet to begin which is the basic idea of implementing the TDD

Step two:

  • Create a new test method, testMusicAnalyserTest that would test a method which is supposed to give music suggestions and info about the queried artist
  • Develop the test describing what is to be achieved; create class MusicAnalyser under src/main/java after declaring in the test package (intelliJ shortcut: alt+enter)

Step three:

  • Create analyse method, after calling it in the test package, which is expected to return some suggestions or info about the artist
  • The first phase of TDD is to develop a test that is bound to fail, we build and run the test in order to fail first
  • Let us now just return null for the analyse method and run it to fail

Step four:

  • Now it’s time to refactor the code so as to make it pass and begin the second phase of TDD
  • Let us do some business logic by returning the music type of the artist; POP in this case
  • Assert to check if same is returned

Step five:

  • Iterate the process of red-green-refactor cycle
  • Let us now improvise the musicAnalyser code to return suggestions from internet if unknown artist is given

Now run the test again, see them pass and the RGR cycle repeats.

Summary:
TDD should be approached as a habit; here’s some roots of discipline that should be practiced during TDD. Here are a few books that give clear and detailed picture about how TDD weighs in Agile development process, along with Intro and Best Practices.

  • Test driven development by Kent Beck
  • Growing object oriented software, Guided by Tests, by Steve freeman, Nat Pryce