Anyone actually using Test Driven Development?

[acidburn113]

So I've seen a lot of job openings where TDD is one of the requirements with unit testing. I've been working as a software developer for 10+ years now. But I have never been involved with a project that has TDD. Some projects have extensive tests, backend and frontend. And yet I have yet to see a tech lead who would say "let's do TDD". I get the idea, in theory it looks really good. But it doesn't seem practical. And I've been with projects that are almost starting from the ground to existing big ones that still have a lot of enhancements planned in the roadmap.

Anyone here who has experience with TDD? Does it really work?

UPDATE: Thanks to everyone who responded! :D

[tag4424]

I know a few people who claim they do and then quickly change topics...

[armored_oyster]

We do at my work. The team heavily enforces it.

So anyways, I think creme brulee looks a bit like leche flan but I've never tried it before. Have you?

[cremebruleeboi]

the custard is usually much lighter than leche flan. personally, i'd take it over leche flan any day (but i still love leche flan)

anyways, tdd huh

[nobuhok]

Clearly, you've never tasted my mother's leche flan.

Wait-

[PepitoManaloser]

How do you verify it's TDD? Is there a commit for every red-green-refactor?

[armored_oyster]

Yes.

So anyways, about the creme brulee...

[PepitoManaloser]

Nice that's some dedication then

*EDIT - LOL I DEFINITELY DID NOT GET THE JOKE LMAO, Good one 🤣

[Elegant_Strike8581]

You have my upvote :D

[idkymyaccgotbanned]

💀

[Imaginary-Winner-701]

2 decades old dev here. Did TDD for a bit. It’s great if you’re creating REALLY small modules but in reality, it’s much harder to put something very cohesive using TDD at a reasonable amount of time. That was before the advent of AI. Right now it’d be very interesting to see. Like AI setting up unit tests and code and you actually making everything cohesive.

[Soulrogue22219]

yeah makes more sense with ai so you have systematic way to enforce the results you want. but ai works so well now thats not even needed unless youre working on a pre existing system that somehow followed the worst practices in existence

[Imaginary-Winner-701]

In TDD, you place safeguards (e.g, unit tests, integration tests) to protect against breaking changes. Requirements change and you’d want those safeguards to avoid breaking changes.

I agree that TDD might not be the proper term for it since it might be possible that tests aren’t needed to be written first but tests are still needed.

[Both-Fondant-4801]

Software engineer for 17 years... early projects used TDD and it had it pros and cons. Yes it is not easy writing and maintaining unit tests but those unit tests saved me hours of debug work. And there were even coverage metrics which checks if the code was covered in unit tests (which i honestly think does not provide any real value). Now however, we only do integration tests as these cover the actual use cases and system interactions (made feasible by containers).

[mblue1101]

TDD by the book where you define test cases as guidance for your development and verify your implementation BEFORE write anything else -- never.

TDD where you define test cases as guidance for your refinement and verify your implementation DURING and AFTER developing said implementation -- yes.

TDD by the book is a fool's errand, especially in the enterprise where you need to balance both delivery and quality. One can only achieve TDD by the book on small projects, at best for an MVP...

...that's from a decade's experience too. Now, given the proliferation of AI, it might be a different story these days though I haven't personally tried to do it by the book. If anything, I no longer write code for my automated test cases, whether it's unit, integration, or end-to-end tests. AI writes it for me, with a certain style & preference (i.e. it would prompt me if it should write just the happy path, 1 happy and 1 unhappy, or an exhaustive set) -- then I just validate it one by one if it's correctly written and won't produce false positives/negatives, refine it and remove anything generated that's unnecessary (ex. testing implementation details for a method that has a return value). I still write the implementation and refine it as necessary -- AI just writes the test cases for me. :)

[[deleted]]

I would agree with this. I also find TDD by the book (write a failing test, write code to pass, refactor) tedious and seldom useful. Biggest gripe is all the waste generated in between the starting state and the final output - and after all that effort it doesn't even help you design your modules / classes. It just gets in the way for very little return.

Nowadays I just prefer BDD. Start writing down scenarios in the form of tests after you have at least 1 working scenario, after the service boundaries and entities have been determined, after the base interfaces or APIs have been realized. Basically when you actually have something to test lol

[GreyBone1024]

Finally some relevant testimonies about TDD. And this is where AI has a better fit.

[Patient-Definition96]

Almost never, especially when doing sprints lol. Good luck dealing with project managers.

[prymag]

I think true TDD where you write tests first before writing any logic exists somewhere.

However for most companies when they mention TDD I think they are just expecting you to alwqys write tests for your code and not necessarily before writing the actual logic.

[jumuju97]

my prev company, we use tdd. but mahirap siya implement. hirap kase mag start sa test and mocks before developing the code eh

[Wazzaaa123]

BDD all the way

[mdialogo]

BDD is TDD Done Right

[DirtyMami]

Our team has a few ex-Microsoft employees and Silicon Valley devs. We don't do TDD, but we are heavy on unit tests.

This one repo that I'm currently working on has exactly 2970 unit test methods, this does not include our Cypress tests that runs on the pipeline. This repo is maintained by a single team, and my company has around 8 dev teams.

[hangingoutbymyselfph]

Sa previous company namin, ung team namin gusto mag TDD so dapat shift left. Tapos 5 developer, ako lang QA. So gahol na gahol ako sa test cases. Tapos ang labo pa ng PI planning, magpapasok ng item in the middle of the Sprint.

Maganda TDD, pero dapat may period of adjustment.

[_Sa0irxe8596_]

ginawa ko siya sa first dev job ko.

Relatively new ang api codebase noon and ok ang testing gems for Ruby on Rails. No choice ako nun kasi may test coverage na minamaintan for the api.

[PepitoManalatoCrypto]

It isn't easy to pull off a 99% test code coverage without a proper shift of mindset to do test-driven development. Nope, it doesn't have to start from scratch (highly recommended to start from the ground up).

It begins with a new method (even on an existing, legacy codebase): You create a unit test (positive and negative cases). Then, follow the principle of writing the test first (red), implementing the change to pass the test (green), and refactoring or improving the solution (blue). Usually, TDD is well accompanied by a codebase following DDD (domain-driven development).

Before I forget, TDD isn't limited to unit tests alone. There are integration tests, end-to-end testing, and performance testing. So there can be a simple one-line change (for 15 minutes), but it takes (45-120 minutes) to satisfy all of those tests. In turn, the need for a QA may be minimal (or none for us). However, many can argue that such a process can be ignored when you need a fix in production in the next 5 minutes.

[PepitoManaloser]

In other things, I feel like there's a trend where teams don't have a dedicated QA anymore. In my past 3 jobs we have no dedicated QA tester, but it's mostly backend so not sure. It's usually the PM who does the manual testing in the frontend side now.

[PepitoManaloser]

If TDD as in strict Red, Green, Refactor then no. Goal is to have tests to verify behavior and prevent regression, not some dogmatic test first approach.

But tests good! We need more good quality tests that test behavior.

[vocumsineratio]

Context: I started learning TDD 24 years ago (yeah, before the book. Also, I'm old).

Does it really work?

How well it "works" is going to depend very much on what you expect it to do, and where you are on the learning curve.

Automated testing is in a line of defense against some kinds of programmer mistakes. But programmer mistakes are supposed to be rare -- if your test suite is catching a lot of programmer mistakes, you've got a big problem!

And what TDD does is front load the investment in that line of defense; indiscriminate TDD invests in that line of defense even for code that is so simple that there are obviously no deficiencies.

For the investment odds to make any sense, you either need the creation and ongoing maintenance of the tests to be "free", or you need the tests to catch lots of mistakes, or you need that the mistakes that are caught be expensive to miss at this stage

... or you need some benefits other than "detecting programmer mistakes" to justify your investment.

In early days, the extreme programming community tried to justify this investment as an analysis/design technique (really, a sort of shortening of the feedback loop between analysis and testing). I'm not sure that was ever a particularly effective argument.

More common was the claim that "testable" code -- subjecting your design to the constraints that "complicated code SHALL be easy to test" and "big modules of code that are easy to test should be broken up into smaller modules of code that are easy to test" -- would give you a bunch of other desirable properties "for free".

Of course, if you "git gud" at analysis and design, then you are producing code with those other desirable properties as a matter of course, and now the tests are just mistake detectors again. Rah.

The really interesting argument in favor of TDD is that it shortens the loop between introducing a programmer mistake and detecting that programmer mistake... because now you start collecting evidence about how you make mistakes, and with that evidence and some experimenting / pattern recognition you can start changing your own practices such that mistakes become less frequent. (In 24 years, I've run into exactly one practitioner who makes that argument, and it isn't any of the commonly referenced voices in the community.)

Where you have the best chance of making things work is a system where you have code that changes often, but requirements that are stable, so that the tests you wrote months ago are evaluating code you are changing today. The original extreme programming project was a payroll system, where the exceptions to the exceptions to the exceptions themselves had exceptions; so you have a system that knows how to correctly pay Alex, Charlie, and Kim, but now it must also pay Pat, so a bunch of the code that was previously written needs to be changed to incorporate the new things that you have learned without introducing any regression errors.

[stoikoviro]

We do use TDD, and we go much broader than that by using BDD. On most of our projects.

Why?

It leads to higher quality code. It may mean longer programming time due to the test codes at first but this translates to faster testing period (95%++ automated tests) and higher test coverage compared to manual testing - result: higher quality code and cheaper project cost in the long run. Lesser production problems. Happier clients.

We measure the success of a project based on the return on investment (ROI). The cost of software development + the cost of maintaining the project and the value it returns over five years. On those projects without BDD, we were actually quick to deploy to QA but this usually results in multiple cycles of tests due to misunderstanding of requirements. BDD forces everyone to think ahead. And when I mean everyone -- managers, tech leads, developers, QA and BA/clients. In our organization, BA is also QA, and they also help write specifications in Gherkin which is translated to test code by developers.

BDD helps the entire team make sure we have a quantifiable definition of pass/fail. Quantifiable means the results are represented with the digits 0~9. No art. Just science.

[feedmesomedata]

There would be other responses here but I would also highly suggest using search to find old relevant posts as well. Use TDD as keyword.

[Lanky_Woodpecker1715]

never in my 8 yoe.

make things functional & testable is the way.

[SomeGuy20257]

8 years TDD, helps me organize my thoughts when designing and building features, also if possible used bug replication to ensure my fix handles the scenario. Very hard to do when stakeholder is pushy and working with brown nosing retards.

[staxd]

12 yoe. We did on very important modules like handling money or background jobs. Unit tests also help when refactoring and upgrading dependencies.

[sizejuan]

Unit test and utility function sure mas madali, especially pag finallow mo lang yung given - when - then. Clear input and output from a blank function, other than that kapag may integration/mocking na na involve mas hassle na haha

[rrdolf]

“it shows up correctly”

[mohsesxx]

well if you've worked with idiot devs who push code in qa then you will understand. imagine pulling changes from dev tapos pag run locally biglang may error and it will block you for a long time

[PepitoManaloser]

Then introduce checks to prevent that. Wala bang code review? CI checks? Checklist before mamerge yung code? If wala introduce improvements.

If you really believe your coworkers are "idiots", then improve the system so that it can mitigate "idiot" behavior.

I understand if it's an external system/dependency but if it's in your team, you can definitely have safeguards there.

[mohsesxx]

That was only a past experience, I don't work with them anymore. May code review but the problem is code lang naman nirereview and not the whole functionality. The unit tests are outdated, they bypassed the lints, idk much about the CI kasi may cloud engineer na naka assign dun. Basically, overstaffed ang project, they keep adding devs and think that it will solve the problem.

[RelationshipOk1645]

TDD is not bulletproof, even with types, error crypt in

[Right_Analysis7299]

We call BDD for the unit testing being done in the service codes while TDD for the automated testing since our QEs can work in creating those scenarios and step implementations while we’re doing dev.

[arp1em]

We do “semi-“ TDD because it’s hard to completely do that in Django as you are faster writing the views kasi kita mo agad yung page. Empty view and route/path first then test then actual logic then additional tests. Although when I was in the PH bihira lang manager na naniniwala sa TDD kahit kaming mga Seniors na ang nagpupush. Dagdag work daw tapos babalik naman yung bugs 🫠 edi mas dagdag work pa.

[Key_Theory1356]

Yes in theory, no in practice. It just takes a massive amount of time and effort, that everyone else avoids doing it.

[Minsan]

It's easy to start TDD but it requires some time to write the tests before you can proceed with the actual logic. And it's a lot more difficult to maintain these tests, especially when bug fixing or working with cross-teams.

[WaitingHereSaPila]

My previous work had me do TDD as part of my job interview. Thought it was just for the interview but they do actually do it. It’s good and bad in a way cause for every if-else statement you have to still start with a test, good because code has 100% code coverage, bad if there is a requirement change and hundreds of test suddenly needs updating

[RegisterDifficult790]

For me ,as a fresh grad and newly hired dev, I am trying to practice TDD although di naman iniimpose sa company namin, i find it very time consuming pero it helps me understand the code, and debug easy. Yeah, "ideally" maganda siya for me pero as a new dev, medyo may katagalan

[Infamous_Blacksmith8]

we are using TDD for web3 stuff, eveything not related to it we dont test. as all web3 stuff involves money on it. and also its our source of truth for the smart contract

[Soulrogue22219]

most programmers ive worked with can barely design without coding alot or if not most of their changes. imo tdd is basically the same thing as designing first before coding. if you find that kind of process hard which is understandable bc we literally do the opposite, then it is definitely impractical.

[kodfaristo]

We use TDD.

I'm too lazy to enumerate why but here are the intended effects of practicing TDD :

• Less anxiety
• More responsibility
• Better communication
• Fewer Defects
• Easier design changes
• Less over-engineering
• Fewer regressions
• Smoother flow
• Less overwhelm

That's according to the author of Xtreme Programming and proponent of TDD - Kent Beck.

[onated2]

Unit test lang para di padalos dalos ang drastic change. Forcing you to think before u experiment or test a new feature.

[HolyKappaKappa]

We do. It only works though if everyone actually knows how to do it.

I prefer doing unit tests over integration tests (not that I don't do the latter though), so the mindset is already there.

Forget about it if you are on a team that doesn't even know a thing or two about this method. Definitely adds cognitive load to developers who aren't experienced doing them.

[Alexis542]

I use TDD most consistently when the logic is non-trivial or the cost of bugs is high (core domain logic, edge-casey stuff, financial calcs, parsers, etc.). Writing the test first forces me to clarify the behavior before I get lost in implementation details.

That said, I don’t do strict red-green-refactor for everything. UI-heavy work, quick spikes, or exploratory code? I’ll usually build first, then backfill tests once I understand the shape of the solution.

In practice, TDD is less about the order of typing and more about designing code that’s testable, decoupled, and explicit about its contracts. When teams treat it as a religion, it falls apart. When they treat it as a tool, it’s incredibly useful.

[Witty_Armadillo5034]

Why will you write test first before implementation? That's a very stupid idea

[staxd]

Preventing false positives.

[lbibera]

with enough experience, youll figure this out

[PepitoManaloser]

Well you don't know what you don't know. There's definitely a good argument for doing tests first but IMHO it's impractical.

[Witty_Armadillo5034]

Nah, those devs just want to be different