Do you practice TDD?

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.

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.

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.

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.

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.

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.

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.

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.

Like all things related to software development, it depends. If there are many defined edge cases specified in the design spec then TDD is an efficient method to develop software. When the software is being prototyped for the first time; however, it is faster for the team to build the features, demo, and UX test first as user acceptance always results in more UI changes.

Once the UI is validated and stable, add basic testing thru the UI and most importantly, instrument all code to catch production errors and deploy to select customers. Customers will do things developers never expected logging new production errors. When production issues are found, fix then add tests to prevent regression.

Keep in mind that testing can double or triple code in a system and test code requires maintenance like all other code which means time. If there are plenty of resources, time, and funding, then TDD is great. If you’re in a startup and the feature has not been validated by the users and no one is paying for the feature meaning it may be removed completely and replaced with a better feature, then TDD will slow down time to market which can kill a startup. MVPs don’t need extensive test cases like a mature product that generates revenue requires.

This approach provides quickest time to market on new features, the most efficient path to fix issues, and provides test coverage for only real failures minimizing code and extra work.

On large projects with 20+ developers it is very important to have TDD and good test coverage as achieving complete understanding of how all feature work with all team members is impossible. Testing provides immediate feedback when something brakes and automates testing so it can be done before every commit if needed.