4 ms·
The biggest misunderstanding about TDD is that you need to do TDD to be good engineer and write good code as promoted by some TDD evangelists. Writing tests is
by avl999 5y ago
The biggest misunderstanding about TDD is that you need to do TDD to be good engineer and write good code as promoted by some TDD evangelists. Writing tests is important, writing good tests is important... what is not important is the order you write the tests or if you follow an arcane set of "rules" about how you should write tests as if they are some ancient divine wisdom someone discovered on a stone tablet that's the key to writing good software.
No... forget about writing tests inside out or outside in, top down or bottom up. Forget about the bs about "TDD is actually there to help you design the code so you SHOULD write tests first to expose flaws in your design". It does not matter as long as you write good tests and feel productive while writing code.
Maybe TDD "rules" and rituals are useful when you are a relative beginner and instead of overwhelming them with a ton of information it is nice to have a set of rules and steps you can follow that have a good chance of resulting in a decent final product. But at a certain point you need to what works best for you and ignore the TDD dogma.
I am not anti-TDD, I practice TDD for parts of the code but do it in a way that if a TDD purist saw it they would term it blasphemous. I never use TDD as a design tool, on the contrary I always design the general structure of a class or a package based on intuition and experience without writing a single line of test code. Then when I have the general design and skeleton functionality of the module fleshed out I jump into tests and start doing TDD to start filling out the functionality, addressing edge cases and so on. Coupling design with tests slows me down as it results in a lot of thrashing between tests and real code. I think a large number of developers feel this way and have never really bought into the "TDD is for design" hype. If on the otherhand TDD helps you design, go for it. The point is that TDD should not be treated like religious dogma that it often is.
The biggest advantage of TDD is the dopamine hit it gives you when a test goes from red to green. That hit is so powerful that I continue to do TDD maybe 50% of the time but don't it dogmatically like TDD purists would want people to do it.
- Aeolun 5y agoI think the thing is, you can absolutely write the code and then write the tests afterwards, but you might end up with something that is hard to test (which is probably an indication your code is not properly modularized). You should take that as a sign you need to rewrite the code you’ve just written, but a lot of people don’t want to trash all (or part of) their hard work and instead bend the tests so that they deal with the code. You now have bad code, and you have bad/fragile tests. I think TDD (when enforced) is mostly meant to prevent people from falling for that.
- xatxat 5y agoI think people with enough experience in software development know quite well if the code they are currently writing is going to be testable or not.
- vmaurin 5y agoTDD is "just" a technique, and being dogmatic about it, is as you say totally pointless. Still I would consider knowing and practicing this technique a "must known" in the industry. When I look back to my 15 years coding : - the time I lost creating bad designed code and manual testing is huge - all the companies and projects I have joined always have terrible designed/unmaintainable code, made sometime by 10y+ experienced people and explaining at least how to write proper test and how to design a code that is testable is always the game changer to increase a project velocity and down the defect rate
- gpderetta 5y agoI never regretted throwing away badly designed code. The learning experience was always useful. Manual testing is indeed a waste of time for the most part.
- jeremyjh 5y agoI don't always write the tests first, I do what seems practical and feasible. Sometimes it feels more natural to write some code to understand the problem I'm solving. That said - there is a problem with writing tests last: You don't actually know if your tests are going to fail when they should, because you haven't run them on a code-base that isn't fully implemented. You can deal with this by stashing the implementation changes and running the tests to confirm they fail where expected, but sometimes this is very challenging because you need a partial implementation to reach some of the failed assertions. This requires thoughtfulness and discipline and so it is hard to maintain this consistently across a team. It isn't possible in a code review to confirm if people have done this, and often it isn't practical to do it yourself as part of reviewing code.