Shift left testing with TDD- Part I

We know that testing is good and we want to do it as much as possible to amplify testing to take it to extreme level. So we want to test our code as early as possible by adopting Test First approach. We can either do it with 'Test driven development' for unit testing of code or 'integration testing of code with Mocks' or we can do it with 'Behavior driven development' aka 'Acceptance test driven development' for functional testing. Purpose of both is test first, fail fast and improve quality of work product. Fixing bugs during build phase is much faster and cheaper than fixing those in production. Hence cost of failure considerably reduce when we follow Test first practices.

Today we will focus on Unit testing with Test Driven Development.

What is unit testing?

Unit is small piece of code; either a function, block or a small class. You need to decide scope of unit in your program. To test that unit of code we write a automated test in same programming language in which our code is written and we execute the test and validate response through assertions, to check if that unit is providing expected output or not . This testing we do at the time of developing our code , not in any integration environment or production. This is called as unit testing.

The intent of unit testing is to find out bugs in code logic at early stage and fail fast. In unit testing, test is written immediately after writing that source code. But usually programmers tend to keep unit testing as last resort in sprint and they used to write them if any capacity is left with them just as formality and whole intent of doing unit testing is failed. Hence instead following test last approach, the recommended practice is write test even before writing your production code and then write a code to satisfy that test and execute the test to verify behavior of your code. This is called as "Test Driven Development(TDD)". Lets see TDD in more detail now.

What is Test Driven Development ?

There are 3 steps or actions involved in TDD.

1. Red: Before writing any piece of code , you write a test to validate that code. You run this test and its fails, because you are trying to validate expected response from the production code which does not exist. Here before writing test we should know expected behavior of that unit of code code , expected input parameters ,so that we can write test accordingly to verify the expected output.
2. Green: Next step is to write the enough production code to satisfy that particular test and nothing more than that. After adding the enough code , you run your test again and test pass. This is called green phase. If your production code is not written as expected, your test might fail again and you need to revalidate your production code and repeat this cycle till it becomes green.
3. Refactor: Once your first test becomes green, you add another test for another possible scenario for that code and repeat the red and green cycle till it becomes green. While doing this, you may find that your production code need some refactoring. There can be some duplicate code, unused variables etc. and you want to fix it without breaking original intent of your code. This is called as refactoring. Here beauty is , you have a safety net already built for your code, through your tests. So even if you break any logic accidently while doing refactoring, your test is going to catch it and it will fail and you will get feedback immediately. Hence you can go back and fix your code and rerun all your tests to make sure every test pass after refactoring of code is done.

In short , TDD is Red, green and refactor cycle followed till you complete development of that particular unit of code. As you have test for each line of code , the side effect is , you achieve 100% code coverage . As these tests are automated one, those can be executed in build pipeline after every successful build to make sure that your code produce same results even after integrating it with other developer's code.

We will see 3 laws of TDD by uncle Bob and FIRST principles of TDD in next article. Stay tuned ..