TDD-Test Driven Development

TDD
       So before beginning this we shall see about the usual manner in which we code. When we are given the problem description we will start to code. End up with a solution. Then give test cases to check if the code works well. But in TDD,

• We take a requirement and write a test case that matches it.
• Run the test so that it fails.
• Modify the existing code so that the test passes.
• Refactor the code so that the code is more efficient and manageable.

       The diagram below explains the working of the TDD.

Scenario:
        So lets consider a scenario where you are asked to write a code to play music using a music player.
        music_player()
        {
        }

        Test 1: should play a song.
        The above test will fail as there is no option to play the song.
        The code is changed to,
          music_player()
          {
                 play_audio(); // it will contain the code to play a particular file
           }

           Test 2: Should allow user to select a song.
            The above code will fail for this test. So we will need to add a new piece of code to choose a file.
           music_player()
          {
                int song_id = select(); //to select a song from the list of songs
                 play_audio( song_id );

           }

           Test 3: Should not list non audio/video files.
           The code will fail as there is such an option is not created.
           music_player()
           {
                show_list();  // list only audio/video files.
                int song_id = select();

                play_audio( song_id );

            }


           Test 4: Should not play a deleted song.
           The code will fail as there is no option to check if the given song id is in the list.
           music_player()
           {
                show_list();
                int song_id = select();
                if( check_updates(song_id) ) // This will check if the song is still in the list
                {
                        play_audio( song_id );
                 }
            }

            Test 5: Should play videos for video songs.
            The code fails as there is no special provision for playing videos. Then we have to change the code as,
            music_player()
           {
                show_list();
                int song_id = select();
                if( check_updates(song_id) )
               {
                     int type = get_type(song_id);
                     play( type, song_id ); //generic play function
                }
            }
            play( type , song_id )
            {
                   switch(type)
                   {
                             case AUDIO: play_audio(song_id);
                             case VIDEO: play_video(song_id); 
                   }
            }

            Here we assume that select(), play(), play_audio() and play_video() are already tested units so we need not check their functionality again. We are concentrating only on the music player().
 
Advantages:
            The good thing about this is if a new programmer wants to add some other features such as categorize() the music files. He will write a test case for it and add the feature and run the entire test cases on the music_player().

            So if there is a problem he can know due to which test case there is a failure and overcome the problem. This gives the programmers some assurance over the code.

              NEGATIVE TEST CASES: These test cases are here to handle situations when the test cases are outside what is defined for the system. For the above music_player() scenario providing non audio/video files and selecting id's of deleted files.
  
             POSITIVE TEST CASES: These test cases are to know how system should react to proper inputs. For the above music_player() giving files to play and selecting files are examples of positive test cases.