Ask HN: Should I force my team to use TDD?
7 comments
You need to choose a working methodology that compliments how the work is done and also helps address pain points. Unless you're showing your clients how you work and using that work process as a selling point to build confidence, you probably don't want to be picking trendy styles of working over what's most appropriate.
All this isn't to say don't use TDD, it sounds like perhaps it's not beneficial to your team. How confident are you in that decision? Perhaps you don't have many defects, but will your product roadmap lead you to complexity that will have them in the future, necessitating better processes later? Processes take time to mature, so maybe now is the time to prepare? Maybe you have very few defects now, but are they expensive or cheap to resolve? I would be considering these questions and looking at TDDs strengths and considering whether it's able to help me.
Additionally, you mention end-to-end testing. So are you validating work by manual tests rather than code tests? How much time are these manual tests taking? How much can you offload to unit tests? Will unit tests offer certainty that manual testing does not? One other thing I can say from experience is that manual testing doesn't scale. Will that be a problem for you?
All this isn't to say don't use TDD, it sounds like perhaps it's not beneficial to your team. How confident are you in that decision? Perhaps you don't have many defects, but will your product roadmap lead you to complexity that will have them in the future, necessitating better processes later? Processes take time to mature, so maybe now is the time to prepare? Maybe you have very few defects now, but are they expensive or cheap to resolve? I would be considering these questions and looking at TDDs strengths and considering whether it's able to help me.
Additionally, you mention end-to-end testing. So are you validating work by manual tests rather than code tests? How much time are these manual tests taking? How much can you offload to unit tests? Will unit tests offer certainty that manual testing does not? One other thing I can say from experience is that manual testing doesn't scale. Will that be a problem for you?
Thank you. Good points to think about.
> I can't say I've personally found any advantages, I don't think I caught any bugs, but who knows... It's the right thing to do... Right?
If you haven't found any advantages after 4 months of doing it, why would you think it's the right thing to do? Lots of people call lots of things best practices, that doesn't mean they're a good idea or the right idea, but some of them may be.
If you haven't found any advantages after 4 months of doing it, why would you think it's the right thing to do? Lots of people call lots of things best practices, that doesn't mean they're a good idea or the right idea, but some of them may be.
In my experience, tests are very important because without them it's much harder to make sure the existing logic is the same after a change or a refactor.
It's a great idea to keep in the back of one's mind how they are going to test what they are working on. TDD is a very structured way of doing that so it could be beneficial but not an absolute necessity.
It's a great idea to keep in the back of one's mind how they are going to test what they are working on. TDD is a very structured way of doing that so it could be beneficial but not an absolute necessity.
This has been a topic of focus for my dev team as well - it should definitely not be forced in my opinion.
All non trivial code additions should have tests but the process with which their written shouldn’t matter
No. If you can’t demonstrate clear advantages and persuade the team you have no credibility forcing TDD or anything else on them.
There’s no one “right” way to develop software. Either you have evidence or you don’t.
There’s no one “right” way to develop software. Either you have evidence or you don’t.
Sure, if you want your best developers to leave. The question "Should I force...?" should always be met with the utmost skepticism. That's not the way to lead.
I can't say I've personally found any advantages, I don't think I caught any bugs, but who knows... It's the right thing to do... Right?
Anyway, my team typically will claim they are too busy, and our end to end testing is good enough. And admittedly I don't think many of our bugs would be caught with TDD.
I'd like to think our software is critical, but we are judged on man hours saved rather than perfect first programs.
Any thoughts on if TDD is our only solution?