Skip to main content

Phases of TDD - Learn by example

Published on

I have already written on getting started with TDD. Let me extend it further and mention in theory what are all the phases involved in a TDD.

Before jumping into this article, I hope you read the getting started with TDD article.  

There might be more steps involved in TDD. However we're just going to discuss the phases of TDD and what do we do in each phase.

/**

 * @disclaimer
 * I'm just preaching what I have learnt & practice
 * Some parts of it could be wrong
 * Please feel free to leave comments if am wrong
 * And I would be happy to stand corrected

*/

The three phases of TDD are the,

  • Red phase
  • Green phase
  • Blue phase

Red phase

This is the very first phase in TDD where we write a test for it to fail. 

Green phase

This is the second phase and immediate next phase to red phase where we write code for the test that we just wrote in the red phase to pass. 

Blue phase

This is the third and final phase of a test where you refactor the test to simplify it down further.

These phases are repeated once again for the next business use case. These definitions might look too less detail until we do it practically. 

[Image source - medium.com]

Therefore, let's take the old example,
Write a method that accepts two positive numbers as input and returns their sum


Case 1 - Function addPositive exists

Red phase

  • it('should have addPositive method'); - The test case for this would fail at this point.

To take this to the green phase, we need to write code for it. 

Therefore, writing code for it,

    function addPositive(a,b){}

Green phase

  • it('should have addPositive method'); - Passes now as we have the method written

There's no refactor required here and so we move on to the red phase of case 2.


Case 2 - Accepts two numbers as input

Red phase

  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two numbers as input'); - The test case for this would fail because it does not throw any error
  • it('should not accept non numbers as input'); - The test case for this would fail because it does not throw any error
To take these tests to the green phase, we need to update the code for it. Therefore writing down code for it,

    function addPositive(a,b){
        if(typeof a !== "number" || typeof b !== "number"){
            throw new Error("Input arguments should be of type number");
        }
    }

Here, if you notice, we have written two cases. One for success scenario and another for failure scenario. Learn more about failure scenario here.

Green phase

Now the above tests enters the green phase.
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two numbers as input'); - Passes now as we have updated the method
  • it('should not accept non numbers as input'); - Passes now as we have updated the method
Once again, there's no refactor required here in the tests. Therefore there's no blue phase and moving on to the red phase of the next case.

Case 3 - Accepts two positive numbers as input


Red phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two numbers as input'); - Passes now as we have updated the method
  • it('should not accept non numbers as input'); - Passes now as we have updated the method
  • it('should accept two positive numbers as input'); - The test case for this would fail because it does not check if the numbers are positive.
  • it('should not accept negative numbers as input'); - The test case for this would fail because it does not check if the numbers are positive.
Now that we have the red phase tests written, we shall update the code for these to enter the green phase.

    function addPositive(a,b){
        if((typeof a !== "number" || typeof b !== "number") && (a < 0 || b < 0)){
            throw new Error("Input arguments should be of positive numbers");
        }
    }

Green phase

The method is updated for the red phase tests to enter the green phase as below,
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two numbers as input'); - Passes now as we have updated the method
  • it('should not accept non numbers as input'); - Passes now as we have updated the method
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
Now that we have the codes written for tests to pass, we could see an opportunity to merge last two test cases with previous two. This is where we enter the blue phase.

Blue phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two numbers as input'); - Passes now as we have updated the method
  • it('should not accept non numbers as input'); - Passes now as we have updated the method
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
Therefore, the blue phase (or) the refactor phase is for the tests and not the code. Thus said, if we refactor the tests, we are going to see the following three tests pass and enter the green phase again,
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
Thus we move on to the red phase of the next case.

Case 4 - Returns sum of the numbers


Red phase

  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
  • it('should return sum of two numbers'); - The test case for this would fail because it does not return the sum yet.
To make the above test enter the green phase, we update the code once again,

    function addPositive(a,b){
        if((typeof a !== "number" || typeof b !== "number") && (a < 0 || b < 0)){
            throw new Error("Input arguments should be of positive numbers");
        }
        return a+b;
    }

Green phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
  • it('should return sum of two numbers'); - Passes now as we have updated the method to return sum
However once again there's an opportunity to refactor and merge the last test and second test. So they enter the blue phase.

Blue phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
  • it('should return sum of two numbers'); - Passes now as we have updated the method to return sum
Therefore if we merge these two test cases and refactor the test, we enter the final green phase.

Green phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should return sum by accepting two positive numbers as input'); - Passes now because it accepts two positive numbers as input and returns the sum as expected
  • it('should not accept negative numbers as input'); - The test case passes because our method now throws error when the input is either negative or if it is non-number.

Case 5 - Input number is greater than max value


Red phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
  • it('should return sum of two numbers'); - Passes now as we have updated the method to return sum
  • it('should throw error if input value is higher than max value'); - The test case for this would fail because in the code, we do not test the input against max value
To make the above test enter the green phase, we update the code once again,

    function addPositive(a,b){
        if((typeof a !== "number" || typeof b !== "number") && (a < 0 || b < 0) && (a == Number.MAX_VALUE || b == Number.MAX_VALUE)){
            throw new Error("Input arguments should be of positive numbers under MAX_VALUE");
        }
        return a+b;
    }

We've made code change for this failing case and now we again enter the green phase.

Green phase
  • it('should have addPositive method'); - Passes now as we have the method written
  • it('should accept two positive numbers as input'); - Passes now as we have updated the method
  • it('should not accept negative numbers as input'); - Passes now as we have updated the method
  • it('should return sum of two numbers'); - Passes now as we have updated the method to return sum
  • it('should throw error if input value is higher than max value'); - Passes now as we have updated the method to throw error if input is not under max value

Now that we have covered all cases, we can classify them as success and failure test suites as mentioned here.

Thus comes the end of the second lesson on TDD. When you follow this TDD life cycle as practice, it becomes even more easier to write code and tests in parallel as you practice.

I hope it was a good read. Do sure let me know in the comments. 

Labels:

Comments

Post a Comment

Popular posts from this blog

Git - Removing a file from a commit

Published on
Once again, another git magic that might be of help to some of you. This research came up when I accidentally added a couple of unwanted files and wanted to remove them from a commit. We all know that to update an existing commit, we shall follow this git magic to amend commits . However, how do we drop changes to a particular file in a commit? While that is easy, it is also tricky. This blog post covers scenarios and respective commands that help you understand what should be done. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be the same as yours. */ There are two scenarios to be handled here, Remove a newly added file Remove changes to an existing file Let's look at them separately, Remove a newly added file This is the scenario where an unwanted file added to the commit. This file might be some config.json that got generated while doing a research on a new testing tool or a bundling tool. Such scenarios are easier. 1. Re
Post a Comment
Read more

Git worktree - guide to flexible folder structure

Published on
As always, let's start with a story why I have written this one down. I have been using git for almost 5 years now and in one of my work places I had to work on the same project but different features in parallel.  Switching between branches back and forth was a costly operation given that I didn't discover commit amend until recently. Even though I'd have discovered commit amend, I'd still have did this. Still did what? I can sense that question deep from your throats. So, whenever I am in a situation to work on multiple features or a feature and a bug fix, I'd have two clones of my repo each with different branches, Whenever a feature is merged or the fixes are merged, I'll delete the clone in my machine and branch in my origin (Gitlab / Github etc.,) Recently when I started writing these git articles, my manager suggested me to learn about Git Worktree and it'll be useful. And when I got free and good understanding of git commit, rebase and stuff, I decid
Post a Comment
Read more

Confluence: 5 quick things that you need

Published on
As part of my work experiments, this week I would like to write down the things that one needs to know in confluence that can up-skill their documentation works. I will cover the following 5 things, How to Anchor link a title? How to Anchor link to a section? How to create a dashing dashboard? Panel - Confluence Macro Layouts - Confluence Tools Content by Label - Confluence Macro 1. How to Anchor link a title? This is the most required thing. Most useful when one has to refer to a section internally on the same confluence page. Let's consider you have a page with three different sections and titles as shown below, In this, if you want to add an internal anchor from a text in paragraph 3 to a title in paragraph 1, you can add it as follows, Choose the word that needs Anchor Click on the link icon from the Toolbar above In the link box, enter #Page Title 1 Click Insert That is it. Your anchor from the selected text to Page Title 1 is ready. This can be tested out in the preview itsel
Post a Comment
Read more