[cgopalan]

My experience is that TDD just ensures that the code is unit-testable. This can lead to more complex code when it need not be complex. I definitely write tests, but my default approach is to make the test simulate how a user would use the functionality. So mostly a higher level test like a system test. And you can do this only when you have a bigger picture of the program that you write (which need not be driven by unit tests, just need to elucidate what the program needs to do and break it into steps). I don't rule out unit tests, but my approach is to start with tests that resemble system tests, and if i specifically need a unit test for a hairy algorithm in a function, use a unit test to help.

Also the higher level you test at, the less probable that you have to change the tests when you change a piece of functionality.

[hitchstory]

It's called TDD not UTDD.

I frequently do TDD with integration and end to end tests. The type of test should be dictated by the nature of the code, which TDD doesnt have an opinion on.

TDD is about following red-green-refactor.

[cgopalan]

Good for you then. I myself have not come across the (loud/louder) TDD exponents advocating for using TDD in system/integration testing, they mostly focus on unit tests. If you can point to some examples, it would be a learning experience for me. If not that's fine too, I am glad that there are voices out there like yours.