Do you practice TDD?

Yes I'll recommend you made this Kata: TDD Roman Numbers it's an excellent excerise to start.

I made it with C# but you can do it with your favorite language/framework.

Yes. The need to feel a little more safe whenever I push some code in production without manually testing if it won't break anythig, the other benefits came along. I can't believe I've worked for so long without TDD.

I used to think that testing was totally useless, then I worked in a company that did no tests at all and everything broke all the fucking time. So I started to write tests and they brought immediate advantages:

• Finding bugs
• Finding regressions
• Making sure the code is properly decoupled

At this time I started to write tests before writing the code. But I never managed to get the test right before the code. My coding process is two-stage:

1. Code the thing grossly first to get the picture
2. Burn everything and code it clean

Now that I'm writing this I suppose that I could have written tests between stage 1 and 2 instead of trying to do it at stage 1 but I didn't (also with time those stages became quite blurry)

But it doesn't matter because now most of what I do is front-end and testing is mostly pointless

• Most things can't be tested (basically: the front-end should look like the design, but how do you test that?)
• There is so many moving parts when you stop doing something trivial (reproducing the output of the API and working with translations for starters)
• Overall it's cheaper to hire interns and have them run the tests manually
• E2E testing is a setup nightmare (again many moving parts)
• Some things I do don't even have tools to be tested (like instant services/chatbots)

In the end, I don't do TDD. It's not compatible with my work process and not compatible with the kind of work I produce.

No, but I see that often people confuse unit testing with TDD, including in this article comments.

I write many unit tests,

but I yet have to found the TDDs utility, at least in my projects. I studied and practice a bit, for many reasons it does not work in an agile env.

Yes. For me, there were three things.

1. A painful experience. I was working on a feature for days, then a wild message arrived. A component that I was using, stopped working. The thing is that I hadn't touch that component for weeks. After a while, I traced it back to a PR from a college who changed one line. Nothing serious, but I don't enjoy this kind of distractions.

2. I was deploying an application to a testing server and the team on the back end had me pointing my requests to a specific port. For some reason, every two days they were chaining the port. So the business side of the team that were testing the app, frequently asked me to check the app because it was not working. So here comes the question: How can I get this kind of feedback faster? I ended up automating these test I blogging about it.

3. A great video on Youtube by MPJ. The main idea is that we are usually working in complex systems, and it is hard for one person to know everything that is happening at all times, so you put that into tests.

I don't use "proper" tdd, but I do write unit and acceptance tests on new code. My company has a lot of old, bad code (I just saw a FUNCTION that was 1000 lines long and used includes in php the other day...) which has no tests and is very hard to test due to the way they are written. Acceptance tests have been very helpful in making new features for web. Unfortunately our DBAs installed a new auth plugin for the database the other day and broke our test stack's ability to query the DB for acceptance tests. Something I have yet to figure out how to fix.

I try doing TDD. Usually its easier when starting with integration tests as described in amazon.com/Growing-Object-Oriented.... We have microservices communicating with each other by REST api, so it's not difficult to write a bunch of tests checking status codes and responses.

As much as I love testing, I really don't do TDD and the reason is pretty simple: I usually (to not say never) understand from the get go what I have to do.

Most of the initial effort is understanding what is required and for me the best way to get to that stage is writing some code which I will eventually throw away.

That said, I don't push a commit without having tests (at least unit tests) covering what I did, but i really cannot say that my development is driven by tests. Not at all.

I'd love to say "yes". But the honest answer is "sometimes".

A lot of other comments have touched on the idea that automated testing in general is more valuable than the process of TDD, and I'd be inclined to agree.

There's never a commit of mine that doesn't contain some tests. The circumstances of the creation of those tests varies depending on the problem that needs to be solved. Sometimes they come first, sometimes after.

What made me want to start doing this? Confidence.

My first question on almost every piece of code I review or pair on is: "How do you know this works?". If the answer involves manual execution or examination of the code, my confidence level is near-zero.

Generally no, I find it doesn't work as a workflow for me and usually doesn't apply to the situation.

The case when I do like it is fixing a bug, having that failing test to have once you've identified the bug makes it easy to leave the task.