Why TDD is bad practice?

Did you listen that TDD is bad? What do you think about it? I have my opinion about it!

TDD is bad because...

• We don't have time to write tests first - I think this is a good point. I sometimes don't have time for that. Why? Because I need to do quickly fix on our code and deploy it. In this case I don't have time to create test after wrote production code too. The even worse case is when we have tested this part of our code and test after change doesn't work. I don't like this, because I must read tests and thinking about repair tests for new logic. I really don't like this. I would like to create new test and remove old every time when I have that situation. What's wrong with the test first on this case? Nothing, because if you have time to write tests after create code, you have time to create test before it. Don't you think so?
• We know how will implement it, but we don't know how testing it - I think a lot of developers have this problem, because we like testing our code. If you don't know what I say at the moment I will explain you. We aren't a good tester, because we think about code. I think QA and testers are ahead of us, because on their life they must tested manually at the beginning of their career. They think about testing like use case. We like testing code. That is our weakness. If you write a method and you don't know how you will use it. I think this method is bad or you don't need it.
• When we have a bug easier find it in debug. After finding it, we easier is fixing the bugged code, than creating test - of course, but I always like automatic my work. When I have a bug, only sometimes I reproduce it like users. I like to write test case for it, because I can focus on my problem without focus on reproducing process. I think You do it too, but you often don't know about it. Did you not do it? Try it. You will save a lot of your expensive time.
• We have a lot of dependencies in our logic, so the easiest way is creating a test after creating and cleanup code - I had had a problem with it too. When I learned TDD I think that like the teachers say "use TDD everywhere", but practice is the best teacher. I always thought TDD is a problem, but the problem was at another point. The problem is on my tests. I have tried to write tests for everything. For strategies pattern, serializers, controllers, services, controllers using serializers using services using database and cache. A unit test is good only for one level of abstraction. If you have a code where you have a lot of abstraction levels, you always will have a problem with testing that. Why? Because you must mocked a lot of things. Maybe we have not SOLID code. Maybe we don't have logic, but only a facade pattern. I don't know why you have that problem, but if you write a test first or later, this won't matter, because the problem is in your code or in your way to create a test. Sometimes better is write IT test or don't write test than write a stupid test.
• We have frequency changed requirement during implementation - I know a lot of people don't agree with me now, but I think we better discovery our business and requirement, when we write test. This is only my observation, but I believe in it. The implementation is the only a one of a lot of solution of this requirement. I think when we create a good quality test, we can change implementation everyone when we have the desire.
• We created a proof of concept and after it easier are creating target code - I think in this case I can tell you the same what I tell you on finding the bug. When I know that the solution working? Only when I tested it.

TDD is bad for people who...

• Create the best code ever, but what we want testing? The best code? The lost time.
• Always create very good quality tests and testable code. If you are one of them You are lucky. Really!

Why TDD?

Because I am the worst tester. I know it. I have a problem with testing code, but not functionality. I have a problem with SOLID code, so I have often thousand dependency. I have a problem with creating entry data. When I write the test, which tested my code, I must use Mockito, when I try testing my algorithm or business logic. I know about my weakness. I don't know it will help me create more testable or readable code, but I am sure this teach me how write better test. How do I know it? Because writing a bad test on TDD is worse than writing a bad test after the production code.