TDD Practices Debate

It sounds a little like you are trying to write all the tests to the spec up front? With TDD you are still allowed to change design choices as you go and as you realise how you want it to behave. That’s why the tests are one by one. In my experience, TDD carries the most value when you really don’t know where you are going, you write the first test and you start rolling, and somehow you end up at your destination and people think you were good at writing code but actually the code was writing it

You're not doing Test-Driven Development if you're writing code and then writing tests, though. You must write your test first, and only after you see it failing, write the code to make it pass. You have to stick to this cadence if you want to put TDD in practice.

Yes, it's a welcomed side effect of TDD'ing, TDD is more of a design tool. But also I have experimented with writing tests before/after the implementation. Code with tests written first seemed to always be just to the point and get one in the mindset of thinking ahead of your edge cases and pin them down

Isn't TDD all about writing tests before coding?

With TDD you write tests first, then ensure your tests fail, then write code, ... for the reasons you mention.

You don't need precise specs to practice TDD. If you have idea of the code you need to write, you can write the test for it beforehand - no matter how often someone might change their mind about the app.Doing so would actually make your life a lot easier when it's time to alter functionality, because now you have well tested and testable code. Code that is written to be tested is usually a lot easier to reason about, to change and extend.If you do it in concise manner and test be

I think TDD purists seem to see no point in unit tests that are not written before the code. That is, if the unit tests were not used to drive the design and implementation of the code under test, they are useless. I find a lot of value in the test driven approach, but this purist view does not make sense to me. I sometimes, or often, write the code first (being able to do so in a repl in languages that support that is even better), when I find it easier to think through the problem in terms of

TDD has always meant to write your tests first. Red, green, refactor. If you're not doing TFD, you're not doing TDD; you're just developing with tests. TDD is test-driven precisely because all implementation code is written to make some failing test pass. Code not so written is by definition broken and does not make it into production. (If you need to try out an idea without writing tests first, that's called a spike and it should be thrown away after proving what you

TDD can be great if you know exactly what you're building and what you must test for, but it gets in the way when you're rapidly prototyping and exploring.It sounds like you're making the mistake of thinking that TDD means writing the tests first. That's not quite right but it's understandable that lots of people believe it given the way TDD is usually discussed.In TDD you should be writing one test first. Then you write enough code to make that test

Write tests first, then code to make them pass. Catch bugs early and create resilient, optimized code. Use small, incremental cycles for frequent feedback. Embrace micro-testing and best practices for successful TDD!