Tip:
Highlight text to annotate it
X
Hello, my name is Nadia.
I am a developer and I try to apply software development's good pratices every day.
I created this channel to share them with you.
Today, I am going to talk about TDD.
TDD means Test Driven Development.
It is a development tool that recommends to write tests before production code.
To do this introduction, I am going to use a kata.
A kata is just an exercice that allows you to pratice.
The one that I chose is called "fizzbuzz".
It is a game where you have to count and display numbers.
We count from one and have to follow three other rules.
When we have a multiple of 3, we have to display "fizz".
When we have a multiple of 5, we have to display "buzz".
And when we have a multiple of both we have to display "fizzbuzz".
Let's start!
I am going to start with the easiest case which is: display "one" when we have the integer "one".
You can see that my test has three sections: given, when and then.
The "given" section is where you prepare all the necessary to your test.
"When" is the execution part.
"Then" is the part where you do all your assertions.
I like to start with the "when" section so I describe in the first place what my test is doing.
So, I get the result of my method call.
Then, I check it has the right value.
Here, I verify that it is equal to one.
I do then the minimum necessary to make my test compile.
I create then the method "display" whithout writing the implementation, just to make my test compile.
Now, TDD recommends to run the test suite before implementing the feature.
Thus, I am going to run my test and verify that it is red for the good reasons.
So, I was expecting to have "1" but I have "null".
This is normal because I haven't implemented the feature yet. I am going to do it now.
The idea here is to implement the minimum necessary to make the test pass.
For example, I can directly return "1".
My test is now green. I can now implement the next feature.
I am confident enough to test that when we have "n" we display "n".
I restart the iteration and I test with the value "2", for instance.
I run all my tests and I check that it is my second test that is red and for the good reasons.
I was expecting "2" but I have "1", wich is normal because my method returns "1" directly.
I implement then my feature by getting my integer and returning its string value. This way, I know that it is going to work for all integers.
I run all my test suite and check that it is green.
I move on to the next feature.
Now, I am going to test that we display "fizz" when we have a multiple of 3.
I am going to test with "6", for example.
I run all my tests and verify that the last one is red.
It is actually red, we were expecting to have "fizz" but we have "6".
I code then the necessary to make my last test pass.
So, I verify that when I have a multiple of 3, I return "fizz".
I run my test suite and I check that it is green.
Perfect.
My feature is implemented. Now, I see that I can do a small refactoring to render the code cleaner.
So, I create a constant field for "fizz" and run the tests again to make sure that my refactoring did not cause regressions.
It is all good! I can do then the next feature.
I am going to test now that we display "buzz" when we have a multiple of 5, as before.
I test with the value "10", for instance.
I run my tests and I verify that the last one is red for the good reasons.
I was expecting "buzz" but I have "10".
It is normal, I am going to develop now the necessary to make my test pass.
So, I do as before, except that I return "buzz" for a multiple of "5".
All my tests are green. Now, I refactor.
So I perform the same small refactoring as previously.
But, also, I see that I can make this part more explicit so that the code becomes more understandable.
Now, we clearly understand that it is for a multiple of 3 or 5 that we have to return "fizz" or buzz".
I run again my test suite to verify that I did not cause any regression.
It is all gren.
I can implement the next feature.
I am going to test that we display "fizzbuzz" when we have a multiple of 3 and 5.
I am going to test with "15", for example.
I run all the tests and I check that the last one is red.
We were expecting "fizzbuzz" but have "fizz".
So, at the beginning of my "display" method, I am going to check that for a multiple of 3 and 5, I return "fizzbuzz".
I run my tests and they should all be green.
Perfect. Now, I do some refactoring to render the code cleaner and I run my tests again to make sure there is no regression.
Great!
We have then implemented all the features that we needed for this game.
We became familiar with TDD. The things to remember are the following:
You have to write the tests before the code.
You have to work by iterations and the size of each one depends on the confidence we have in our code.
Finally, don't forget to refactor, for each feature and when all tests are green, then you have to run your test suite again after refactoring.
Thanks for following me. I hope you liked it and see you for my next episode.