TDD is a personal practice

I agree in general.

To me, TDD is worth learning in the same way that lots of courses one might take in college are valuable knowledge even if the literal practices aren't used daily. TDD should probably be thought of in that sense.

I think because it's such a religious topic, I feel like it's not treated in such practical terms.

I think so , TDD is tools and use it when need it . but I think TDD is name for more generic tools that do best but when you want to use this tools should select one that proof your needs

Hmmm, I find the term TDD practitioner to be problematic in the same way Agile practitioner is. Agile is simply the philosophy laid out in the Agile manifesto. A bunch of non-technical people took the concept of Agile and turned it into a bunch of process and methodologies with complex (rigid) flowcharts determining how work should be delivered. Agile isn't something you practice, it's a philosophy that informs your work.

The same is true for TDD in my opinion. TDD is a philosophy that you apply to your work.

A few things I (personally) consider to be test driven development:

• Writing some code, saving and then running the code (or refreshing a browser) to see if it works.
• Using HMR for a front-end build system.
• Writing a script to be run when files are updated, that will result in a success or fail state.
• Running some requests in a .http file or a postman collection after making some changes.
• Defining a test suite which encapsulates any or all of the above.

All of these things have something in common: they are a defined set of actions that I will perform to verify the correctness of an implementation.

I don't advocate for or against TDD. But I'm lazy and can't be bothered performing all of these actions manually every time I make one tiny change. I'd rather just define the actions once and then let the machine do it for me.

Take HMR as an example: so many front-end project I've worked on implement HMR but don't actually implement it.

You might see some call in the app index like this:

// index.ts
if (module.hot) {
  module.hot.accept('./some-module.ts', reloadFunction);
}

Great! Every time I save a file the browser will reload and all state will be reset. The only module being replaced is the top level index.ts module. Everything else is thrown out and I have to point and click at a bunch of things to get back to the required state to actually verify the change.

In reality, every module should define some method for its replacement:

// some-module.ts
if (module.hot) {
  module.hot.accept('./module-dependency-a.ts', () => {
     // define how module dependency a should be replaced when 
     // some-module is updated.
  });

  module.hot.accept('./module-dependency-a.ts', () => {
     // define how module dependency b should be replaced when 
     // some-module is updated.
  });
}

This is how you implement HMR, and it gets really tricky and verbose really fast, and after many years of dealing with these kinds of annoyances (and not being given the time to apply HMR effectively) it becomes much simpler to write some tests with a tool like Cypress, wdio or similar:

describe('some feature', () => {
  beforeAll(() => {
    cy.visit('/path/to/view');
  });

  it('should show some stuff', () => {
    cy.contains('Click Me').click();
    cy.contains('Some Stuff').should('exist');
  });
});

It's objectively true that running this test allows me to verify the correctness of my implementation much faster than:

• Alt tabbing to my browser.
• Shift alt tabbing back to my browser because I have too many apps open (so many times)
• Typing the path into browser address bar or locating and clicking a link.
• Locating the appropriate control to interact with and performing the interaction.

In my experience, it's also true that this kind of tooling allows me to do a number of other things that would be very hard without automation:

• Perform drastic changes in my implementation without worrying that everything will break.
• Migrate some legacy code to [insert shiny new technology that a PM heard of so now we should rewrite our entire codebase to use it here].
• Swap out one dependency for another.
• Refactor and clean up my messy code before sharing it with my team.
• Identify redundant and/or dead code (the only thing coverage reporting is good for IMHO).
• Understand how different components in the system are expected to behave.
• Verify that the business requirements (as I understand them) are implemented correctly.
• Verify that stakeholder's acceptance criteria will be met by my implementation.

This last one is the biggest boon for me personally. Whenever I receive a QA test plan, my first task is to define these as automated tests. This frequently helps me avoid missing details in the acceptance criteria. If the QA test plan fails, then these tests fail, meaning the implementation is not ready for testing.

If you haven't read Kent Beck's Test Driven Development: By Example, I strongly encourage you to pick up a copy. He's the person who developed TDD originally, and you'll find that his opinion is much aligned to yours. TDD as a paradigm is just an approach you can use to verify correctness.

I'd challenge you to read the book, then attempt to cover the public facing facets of a project you're working on just for kicks. You'll find the process illuminating.

From the book's preface:

TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. "What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure, it's TDD. You were aware of the gap between decision and feed-back, and you controlled the gap deliberately.

That said, most people who learn TDD find that their programming practice changed for good. Test Infected is the phrase Erich Gamma coined to describe this shift. You might find yourself writing more tests earlier, and working in smaller steps than you ever dreamed would be sensible. On the other hand, some software engineers learn TDD and then revert to their earlier practices, reserving TDD for special occasions when ordinary programming isn't making progress.

If Kent Beck doesn't advocate for TDD first for everything then anyone who says so should probably read this book also :)