Why TDD is bad, but we should use it?

Today, I have given you some thought about TDD. This is a summary of my investigate and using TDD. I think this will be something new for you. The fresh information and looking for topic from different site.

What is TDD?

I know that you read about TDD, before you are looking at our blog, but to remind I tell you something about it.

In TDD important things are three states:

• The test is not passed,
• The test is passed,
• Refactoring all code, which you have

This is a short cycle. I think the best time for beginners is 30-60s for one of this cycle. The professional programmers can increase the scope and time for one cycle.

About TDD and how you should write in this method you can read a lot of on the net.

What is TDD for me?

My opinion about TDD I slice for six categories this is the tools to learn how write a good quality test, it doesn't the determinant for good quality product, enforce the discipline, the ordeal, time absorber and the technique which is strove for self-destruction.

The tools to learn how write a good quality test

The first thing about TDD, which I want to tell you, is the TDD is very bad for testing code. I try it and it never is easy for that. However the TDD is very good for testing functionality. What's the difference is?

The difference is in approach. When we are testing functionality we want use our function. We want to give its a parameter and get some result. This is very good for testing and those tests will be good quality. The problem is when we know the code. We can use Mockito and stub a method which we are not interested. I think sometimes it is good, because we have a communication with other systems or database, but a lot of places, where I saw using it, It is not used for that.

The challenge for you, try to write in TDD test which you are mocking the other service and check if this service is use one... This is very hard. My first contact with TDD was finished, because I lost a lot of time. I try to write tests like previously. Test for code! TDD gives me a lesson, why my tests are bad. The answer was my tests was testing only code and I create a wall for my code. Every change in my algorithm or service has been associated with changes in the tests. Even if the logic of my functionality is not changed.

It doesn't the determinant for good quality product

The problem with TDD is that we can do everything the same like writing without TDD. This is only awkward. A lot of people say "Use TDD! You will be have 100% code coverage.". Yes, you will have, but the problem is what the quality of this test will be. Yes, TDD can help you do quality test, but you are responsible for writing that test correctly. I think if we want have 100% code coverage, we can write the test which step by step read line of our code ;)

The second problem is with the place where we can't create a good quality unit test. Sometimes we need to test manually, sometimes we need to test integration of our component. This is necessary and TDD is only for one of test layer which we should use.

Enforce the discipline

Programmers are lazy. We don't like to do something unnecessary. Ok, maybe sometimes. Please answer for my question. How many times you are opting out of testing, because you were testing is manually, you don't like writing tests, you don't need test for that or you don't have time to test? This is incorrect, when you use TDD. If you write tests first you will always have a test for your code. There is no excuse.

The ordeal

A lot of things I needed to change in my mind, because I want to write in TDD effectively. These things are:

• Write good quality tests,
• Greater commitment to tests,
• Implement only one thing at a time,
• Frequent refactoring,
• A lot of time runs tests,
• Learn how use the shortcuts,
• Forget about my previous practices,
• No excuse,

and more little things which change my mind about programming.

This is very hard to change all of them. You can do it slowly, a lot of these things help you write your code effectively without TDD too, so you can learn it in another time. I think this was a good lesson for me and all of them learn me something else, so I don't think this time is lost, but I spend a lot of time for learning something other than a programming language.

Time absorber

I think a time is very expensive. I try to write effectively in TDD and always I do task slower. When I know how functionality should be implemented I always waste my time for TDD. A lot of people told me that TDD is faster than another way to implement. I don't think it is true, but maybe you give me an evidence of that argument? During write functionality and tests using TDD we must run a lot of time tests. This is time costly too.

Of course, I found places where TDD is good for using, when we need do something faster. The first place is for bug searching. When we are implementing test first, we have an easy way to reproduce this bug. This is faster than run your environment to debug. Additionally, you have bug coverage. The second place is when you are writing very unusable code and you don't know how write tests for it. In this case your work can be faster. The third place is when you don't know what you functionally do. I think this is a good place for writing test first. Why? During the writing test you read your code and learn it. This is a very fast way to get a knowledge about code (good for new employees).

The technique which is strove for self-destruction

If you know how to write the best code and tests. If you have a discipline for creating these tests. Why you want lost time to write using TDD? This is why I think this is strove for self-destruction, but I learn how write, test and good code every day and this is a long way to be a master of programming, so I think I will be using TDD in all places where I can.

Summary

I think the TDD is very helpful, but time absorbing. I want to recommend you writing tests first, before the functionality. It gives you all the advantages of TDD, but I don't think you should use TDD. This is only for your decision. I hope this post is helpful for you. Thanks for your attention.