Seriously, does anyone really use TDD? It sound good in theory, but generally the devs are already used to implementation-first and are not willing/disciplined enough to change their mindset.
I think the biggest disadvantage of TDD is not taking into account how freaking lazy developers are in general.
Or maybe I just wasn't willing enough to make the change.
Thoughts?

Shu-ha-ri

Do it 100% with the rules first, rhem start experimenting and then make your own rules

The most important thing I got from tdd is how to write testable code

I think it's important to learn how to test properly, so you can create easily testable code from the beginning, which makes your code much cleaner in general. Doing tdd on a project might help learning that quickly. But still I'm also lazy, so yeah I write tests afterwards, usually when I'm procrastinating writing "real" code and don't want to feel unproductive. I'd call it test oriented programming. For me that's a good compromise between my perfectionism and my lazyness.

@alexbrooklyn @notoriousmonk Yes.

Try TDD as intended first. Then change it to fit you.
Most devs will Learn to write testable code, and start writing their tests after (plus refactoring as needed)

I often find myself doing both. Sometimes I have an idea for a test while I’m building a feature and want to write it before I forget, or write tests during because I’m about to refactor something and want to ensure it both works as-is and that my pending changes won’t break the behavior.

What others have said.

You start at tests first, but then management gets in the way. Either w deadline gets shrunk to shit or a project pivots so hard you are glad you didn't write those tests in the first place, nothing like writing ~140 tests just to have things pivot and you end up throwing them all in the trash.

So you end up with tests after implementation to ensure any future work doesn't introduce breaking changes (unless deliberate)

Learn to write clean, well planned, testable code, and you won't need to
have a test waiting for you to prove it works, you should be able to read the code and determine what goes in, and what comes out without running it.

Tests just enforce that what your code does now, will continue to do so later when something is changed.

Basically what @Root said though I tend to be conservative about writing tests first. Usually I sit down and do one feature at a time, which includes both the code and the test.

As she said, sometimes there's a feature I want and will write a test for it first just so I don't forget. I like to place "markers" in my code to force me to look at places again in the future.

I think TDD is dubious. The design shouldn't be driven by tests, but by business requirements - which in turn also should drive the tests.

Also, you're no less likely to have bugs in the test code than in the actual code. Actually even more because exhaustive testing code dwarfs the production code, given the state space.

So you can't test exhaustively anyway and have to choose - but based on what? By suddenly taking the smart pill when writing the test cases? Why not just taking that pill when writing the business code?

It's more likely that you don't take the smart pill in either case and have the same misunderstandings in both business and test code, which is why the tests shouldn't be written by the same dev in the first place.

About the only advantage I see is that the TDD order makes sure that there is any test code at all instead of just cutting down on the verification phase when the release date approaches. But that points to a process deficiency with QA lacking power.

Yes.

I find it valuable to write tests first, as it gives me time to properly think things through, and insight into what I'm really doing.

Especially for larger implementations.

It's also very valuable to be able to quickly get an overview from test stories.

For documentation, I very often just rephrase my tests into a document 😊

I don't do TDD but I almost always make my test be the codes first user. That gives a bit more freedom but still makes sure there is test and it's easy to debug the plumbing.

@Fast-Nop I agree with you but thinking about how your code can be tested makes sure it has it's dependencies and interfaces straight (testable code is better destined code in general)

@hjk101 That's a mixed bag because it may as well be riddled with artificial interfaces, making the whole thing more complicated and thus more bug-prone instead.