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?

  • eksb@programming.devEnglish
    0·
    3 years ago

    Two rules:

    1. All code gets reviewed by a team member before getting merged.
    2. Fail code reviews if there are not sufficient tests.
    • Skyzyx@lemmy.worldEnglish
      1·
      3 years 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.

  • lysdexic@programming.devEnglish
    0·
    3 years ago

    Here’s a way to convince a team to write unit tests:

    • setup a CICD pipeline,
    • add a unit test stage,
    • add code coverage calculation,
    • add a rule where unit tests fail if a code coverage metric drops.
    • if your project is modularized, add pipeline stages to build and test and track code coverage per module.

    Now, don’t set the threshold to, say, 95 %. Keep it somewhat low. Also, be consistent but not a fundamentalist.

    Also, make test coverage a part of your daily communication. Create refactoring tickets whose definition of done specifies code coverage gains. Always give a status report on the project’s code coverage, and publicly praise those who did work to increase code coverage.

    • Reader9@programming.devEnglish
      1·
      3 years ago

      Focusing on code coverage (which doesn’t distinguish between more and less important parts of the code) seems like the opposite of your very good (IMO) recommendation in another comment to focus on specific high-value use-cases.

      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.”

      Code coverage is an OK metric and I agree with tracking it, but I wouldn’t recommend making it a target. It might force developers to write tests, but it probably won’t convince them. And as a developer I hate feeling “forced” and prefer if at all possible to use consensus to decide on team practices.