TDD — Part I, Theory

5 min readDec 21, 2021

You’ve heard from lots of programmers about TDD and the importance of it, and to be honest, it is one of the important subjects for every programming field.

In this article, we are going to discuss the theoretical aspect of TDD and in the future, we will cover the practical part for Android developers (cause I am an Android developer).

TDD is standing for Test-driven development, according to Wikipedia it means :

software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases

There’s a really important sentence in this paragraph before software is fully developed, TDD is a methodology which you will approach your implementation from the test, that means at the very first step you have to write your test, the test represents the validation of then expected functionality and then you make that validation to succeed.

Ok, we talked about the TDD but what is a Test? well, it’s just a block of code that validates another block of code, nothing really complicated :)

Now you may think about why we should use TDD? Let’s mention some advantages of TDD to you :

Making developing faster: how we can achieve more speed while we are actually writing mode code? well, the answer is by writing a test you will reduce your debug time.
Maintenance: lots of time you will face a situation and that is when you develop a new feature and the old features start to be broken :( really painful right? well by writing tests you can be sure about the old features, if anything goes wrong you’ll be informed of that.
Documentation: this is really helpful, most of the time you write the name of the test with the understandable sentence which gives you a guide about the duty of that code, besides that the output of the code will show you the proper result, so if anybody outside of the project joins you, they’ll understand the functionality of a code by looking at the test related to that code

We have 3 types of tests:

Unit test: it’s just a simple block of code that tests another block of code, think about you have a class like Calculator with two operators plus and minus, now we will have two unit tests for approving their functionality
Integration test: think about you have class A and class B, these two classes are working together and became a module with each other, an integration test is a test which will test the relation between components
End to End test: testing a flow from beginning to the end, because it’s going to test a flow so it will be expensive to implement.

(there are more types than these three but it’s not related to our discussion)

Let’s see a pyramid provided by Google :

as you can see our most tests should be on Unit category, then integration and at the end, it should be E2E, and it makes sense, because you have plenty of functions to test (Unit) and you have a couple of Module/Features (Integration) and you have some flow (E2E).

and now what qualification should a test have?

Fast: the test must run as fast as possible
Short: it’s just a test, not an implementation so it should be short as possible
Independent: a test must not depend on another test
Repeatable
Timing: It’s important that you write the test before the actual implementation

Ok now let’s see a really simple unit test example and then we’ll continue this article on Part II

Before we write a test we must know the proper flow of writing a test which is TDD lifecycle:

When you want to write a code first you must write the related test, on the RED phase you write a test that is going to be failed (because there is no code to test), then you make that test passed by writing the actual code of your feature or … and that is GREEN phase, now you have your test and your production code so there is just only one step remains which is BLUE and that is refactoring, on this phase we can refactor both test and actual code (and sometimes there is nothing to refactor)

I want to do this example in Kotlin, when we are using Kotlin/Java we can write our tests by a framework called JUnit, you write your test code in the test folder and the implementation on main (or whatever it is depending on your platform/framework or etc)

consider we want to write a calculator with a simple plus and minus, firstly we must write our test, we want to test the plus function so we start:

as you can see our test will face compile error and it’s good, now we know what is the minimum of code we need to pass this test, now we create a Calculator class: