fsdghrth3

> TDD is not a testing process. It is a design process.

The article actually discusses whether this is accurate or not. TDD started out as a testing process but got adopted for its design consequences which is why there is a lot of confusion.

Naming it test driven design would have gone a long way to help things and also resulted in less cargo culting. "Have to TDD all day or you don't do TDD"

See my other comment below. I don't recommend doing it all the time specifically because with experience you can often skip a lot of the rgr loop.

> Everyone understands the idea, it's just a massive time sink for no more benefit than a test-after methodology provides.

This is not something I agree with. In my experience, when TDD is used you come up with solutions to problems that are better than what you'd come up with otherwise and it generally takes much less time overall.

Writing tests after ensures your code is testable. Writing your tests first ensures you only have to write your code once to get it under test.

Again, you don't always need TDD and applying it when you don't need it will likely be a net time sink with little benefit.

I use TDD as a tool. I find it quite heavy handed for maintenance of legacy code where I basically know the solution to the task up front. I can either just rely on having enough existing coverage or create one test for my change and fix it all in one step.

The times I actually use TDD are basically limited to really tricky problems I don't know how to solve or break down or when I have a problem with some rough ideas for domain boundaries but I don't quite know where I should draw the lines around things. TDD pulls these out of thin air like magic and they consistently take less time to reach than if I just sit there and think about it for a week by trying different approaches out.

> This ultimately means, what most programmers intuitively know, that it's impossible to write adequate test coverage up front

Nobody out there is writing all their tests up front.

TDD is an iterative process, RED GREEN REFACTOR.

- You write one test.

- Write JUST enough code to make it pass.

- Refactor while maintaining green.

- Write a new test.

- Repeat.

I don't want this to come off the wrong way but what you're describing shows you are severely misinformed about what TDD actually is or you're just making assumptions about something based on its name and nothing else.

React is great. Vue is wannabe angular (not sure what version though was it 2, 3 or 4 now?) svelte is too busy shipping bugs to fix any and I don't even know what the others are.

Reading these comments make me sad. It's like everyone has forgotten the cookie cutter server architecture pattern.

https://dzone.com/articles/monoliths-cookie-cutter-or

I really don't understand microservices for most businesses. They're great if you put the effort into it but most business don't have the scale required.

Big databases and big servers serve most businesses just fine. And past that NFS and other distributed filesystem approaches get you to the next phase by horizontally scaling your app servers without needing to decompose your business logic into microservices.

The best approach I've ever seen is a monorepo codebase with non-micro services built into it all running the same way across every app server with a big loadbalancer in front of it all.