Ask HN: How to convince big tech team that tests and code quality matter?

Have you considered that for this business or function within the business, maybe it doesn't matter?

> This must lead to a lot of problems which I'll only face after ramping up, but even onboarding is painful if you don't have e.g. clear automated testing set up.

Maybe you'll learn why this is not the case after several months of working in your new role.

Wait until a bug comes up, fix it, write a test for it, then describe the problem, fix, and test on the next stand-up. Do that a few times and eventually others will catch on without correction or conflict. In short, just raise the bar.

Depends on the state of the culture. It has to be at least "fixable" with somewhat open-minded people at the top. There are 10x more people who try to fix cultures but end up burning out and being a scapegoat for everything.

The question that matters is not whether automated tests improve code quality and productivity.

The question that needs to be answered is "if I took the time I previously spent on automated testing, and instead spent it on something else like code review or design review, would that result in greater code quality and productivity than automated testing did?"

And phrased that way, you see it's not a dichotomy. It depends on what you would spend the time on instead of automated testing. It depends on whether you already had peer review in your process. It depends on what sort of automated tests you spend time on. It's very hard to say something general without those details.

----

Note that I'm not taking a stance against automated testing. I prefer working in a test-first style myself. I'm just saying it's not that simple.

It takes a little time for people to see why testing is important. Since you're new to the organization, tread lightly and keep an eye out for places where testing can really make everyone's life better.

I've found that there are a few key junctures at which people take to testing. Here are some:

1) When dead-simple unit-tests catch old bugs. If cos(0) doesn't return 1, there's a problem.

2) When unit tests, for the first time, catch an important new bug in code they're writing.

3) When there's enough testing coverage that you can rip the guts out of a function, install new guts, run the tests, and be certain that everything is fine.

4) When good coverage newly applied to old code finds really subtle very old bugs in code everyone trusts.

Use the easiest-to-use unit-testing library you can. If there's no test-coverage today, some testing is worlds better than no testing. Once people can see for themselves how helpful it can be, the organization can get fancier if it needs to do so. I absolutely love GNU Octave's testing framework [1], as the syntax is as simple as

  function r = foo(x)
     r = x+2
  end

  %!assert (foo(3) == 5)

When it's easy, people take to it like water. I perpetually emphasize to students the importance of writing the most-boring/simple test first.

[1] https://wiki.octave.org/Tests