43
How do you get your team to write tests?
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Aug 2023
43 points (100.0% liked)
Experienced Devs
3978 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
This could be a good opportunity to introduce the concept of test-driven development (TDD) without the necessity to “write tests first”. But I think it can help illustrate why having tests is better when you are expecting to make changes because of the safety they provide.
“When we make those changes, wouldn’t it be great to have more confidence that the business logic didn’t break when adding a new technical capability?”
This seems like a reasonable statement and I sort of agree, in the sense that for existing production code, making a code change which only adds new tests yet also requires refactoring of existing functionality might feel a bit risky. As other commenters mentioned, starting with writing tests for new features or fixes might help prevent folks feeling like they are refactoring to test. Instead they’re refactoring and developing for the feature and the tests feel like they contribute to that feature as well.
I doubt that by now the concept of TDD is unheard of to any professional team. Name-dropping concepts actually contributes to loose credibility of any code quality effort, and works against you.
Also, TDD's credibility is already low as it piles on the requirement of spending unordinate amounts of extra work effort on aspects of a project which don't deliver features, and thus it's value-added is questionable from a project management perspective.
One aspect that does work is framing the need for tests as assurance that specific invariants are verified and preserved, and thus they contribute to prevent regressions and expected failure modes. From my experience it's far easier to sell the need for specific tests if they are framed as "we need assurances that this component does not fail under conceivable usecases" and specially as "we were screwed by this bug and we need to be absolutely sure we don't experience it ever again."
Agreed - this is the specific aspect which I hoped would be communicated by studying TDD a bit!
The team is afraid that making changes will be more difficult when tests exist, but TDD (or maybe a more specific concept like you mentioned) demonstrates that tests make future changes easier.
And I specifically advocated not to follow “write tests first”.
OK. If I were having an in-depth discussion with my team of fellow developers to convince them to start writing tests, I don’t think that’s name-dropping.
I think the best thing to do with TDD is pair with or convince devs to try it for a feature. Coming at things test first can be novel and interesting, and it does train you to test and use tests better. Once people have tried it, I think it broadens your use of tests pretty well.
However, TDD can be a bit of a cult, and most smart and independent people (like people willing to work at a <20 person company) will notice that TDD isn't the silver bullet it's proponents make it out to be.
I think it depends. If you have to refactor in order to test, you probably built it poorly the first time around.