What is TDD?
TDD - Test Driven Development is a software development approach in which test cases are developed to specify and validate what the code will do. In TDD the tests are not done at the end of the software development, the tests are done before writing any production code.
Why use TDD?
- Is your code difficult to test?
- Don't you know if you have 100% test coverage on the project?
- Are you afraid to make changes to the project because you don't know where it will go wrong?
TDD solves these and other problems because with the laws of tdd every single line of code that you write will be tested.
The three laws of TDD
1.You are not allowed to write any production code until you have first written a failing unit test;
2.You are not allowed to write more of a unit test than is sufficient to fail and not compiling is failing;
3.You are not allowed to write more production code that is sufficient to pass currently failing unit test.
You begin by writing a small portion of unit test. But within a few seconds you must mention the name of some class or function you have not written yet, thus causing the unit test to fail to complete. So you must write production code that makes the test compile. But you cant write any more code than that, so you start writing more unit test code.
Round and round the cycle you go. Adding a bit to the test code. Adding a bit to the production code. The two code streams grow simultaneously into complementary components. The tests fit the production code like an antibody fits an antigen.
Conclusion
TDD allows us to be more productive since the project only grows “if I can say so” after all the tests have passed.
Once the TDD is embraced it will be a step towards the Clean Code.
In the TDD scenario developers need to be very disciplined because sometimes when the calendar starts to get tight some tests may start to be ignored and if you haven't tested the code how will you know there is a hidden bug ?.
Cheers,
Bc.
Top comments (7)
I believe the reason why TDD is not becoming mainstream is because there is some "ambiguity" about it for most developers, and the other reason is deadlines.
Both developers and managers/product owners/clients believe the TDD makes the development process LONGER, which is why it is not becoming that much popular in lots of companies.
But with time, and when the product continues, all of them will wish they have tests. And for developers, I think for easy tasks maybe tdd can slow you down at first, but for complicated tasks, man it makes you verryyy fast.
But because lots of people think tdd slows them, so they do not try it.
That's my problem. I REALLY wanna try TDD, but the slowing down part stops me from venturing it.
So do you write TDD for each and every part of your business logic, or is it that there's some things that are not worth tests, like simple small modules/classes?
That is a great question. The reason behind tdd, or tests in general is to ensure your logic works as expected all the time. And that is why it makes you faster, because its all about confidence.
So for me, the answer is yes I test all business logic. If it is simple then its test will be very very easy but you will ensure that your product works as expected all the time.
And another benifit I notice is that if you are reading a code you wrote long time ago or other people code, its easier to start from tests, because the have to be easy and you can easly spot the inputs and outputs of your component.
Nice read.
10x
Very helpful, thank you for the content.
Great job 👌🏾