this post was submitted on 14 Aug 2023
43 points (100.0% liked)

Experienced Devs

4008 readers
13 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:

founded 2 years ago
MODERATORS
snowe
jmk1ng
drewsiferr
43
How do you get your team to write tests? (self.experienced_devs)
submitted 1 year ago* (last edited 1 year ago) by kersplort to c/experienced_devs
29 comments fedilink hide all child comments
 

I'm like a test unitarian. Unit tests? Great. Integration tests? Awesome. End to end tests? If you're into that kind of thing, go for it. Coverage of lines of code doesn't matter. Coverage of critical business functions does. I think TDD can be a cult, but writing software that way for a little bit is a good training exercise.

I'm a senior engineer at a small startup. We need to move fast, ship new stuff fast, and get things moving. We've got CICD running mocked unit tests, integration tests, and end to end tests, with patterns and tooling for each.

I have support from the CTO in getting more testing in, and I'm able to use testing to cover bugs and regressions, and there's solid testing on a few critical user path features. However, I get resistance from the team on getting enough testing to prevent regressions going forward.

The resistance is usually along lines like:

  • You shouldn't have to refactor to test something
  • We shouldn't use mocks, only integration testing works.
    • Repeat for test types N and M
  • We can't test yet, we're going to make changes soon.

How can I convince the team that the tools available to them will help, and will improve their productivity and cut down time having to firefight?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] eksb 26 points 1 year ago (2 children)

Two rules:

  1. All code gets reviewed by a team member before getting merged.
  2. Fail code reviews if there are not sufficient tests.
[โ€“] sip 2 points 1 year ago (1 children)

yea but if we both aren't really keen on writing tests and I review you, it would be in my lazy ass' interest to ๐Ÿ‘ without tests.

[โ€“] CodeMonkey 1 points 1 year ago (1 children)

That should be a disciplinary issue. The engineers in question should be brought forth in front of management to explain why they thought that this particular change should be exempt from testing and why this was not explained, in detail, in the code review.

[โ€“] lysdexic 9 points 1 year ago

That should be a disciplinary issue.

And that's how you get teams to stop collaborating and turn your work environment to shit.

[โ€“] [email protected] 1 points 1 year ago* (last edited 1 year ago)

I think that instead of "forcing tests", you should instead focus on "proving quality." You think that works the way you thought? Cool. How do you know? What if they were to use 128 NUL bytes? Would it still do the right thing? Cool. How do you know?

Ensuring quality is a larger concept than simply writing tests, but writing tests is definitely part of it. I think if you aim higher and teach the provability of quality, then the better engineers will self-select by starting to write tests.

"If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea." โ€” Antoine de Saint-Exupery

Additionally, if you're one person against the world, you're going to have a tough time. Build alliances. Partner with people who will reinforce the message. If you are the only one telling them something they don't like, they will shun you for it. But if you partner with allies who all have the same message, people are more likely to start to listen. It starts to become a community.

And if all else fails, prove the value of tests by going first. You can't force anyone to do anything. But you can start doing this yourself. At some point, if code gets called into question, you can look at the tests together to see what's covered and how that thing is supposed to work. It's all part of letting the robots do what the robots are good at, which frees you up to do the things that you're good at.