[iraliaf]

I just started working at a 15-person startup where I am on a small team of 5 devs. People typically "don't have time to write tests" and are encouraged to pump out new shiny features every 2 weeks.

I am a new to development but I've noticed that lots of errors pump through code where "No method X defined for nil object" or something like that. I wonder if I could somehow make the case that we'd spend less time reacting to problems and bugs if we spent more time up front writing tests that could give us more than 19% code coverage.

Does anyone have advice for starting this conversation with my boss or during one of our standups? I know I could somehow pitch the value as "less problems later for more time spent now" but is there a more effective way to say it?

[vanjajaja1]

Given that you're new to development, you'll probably lack the sway to get people onboard with just words. It's likely that the team already knows about testing and the benefits of it (its not a secret, the text is everywhere,) and yet they choose to not do it still. They believe tests will slow them down, probably based on past experience, and using the words of people who are not there on the front lines is unlikely to sway them.

To get out of that situation, I'd recommend leading by example and showing how you have personally managed to use tests, in the space they are operating in, to make your life better and develop faster. Once you have something that has provably worked for you, you can start evangelizing it and onboarding other people.

[orbital223]

> I am a new to development but I've noticed that lots of errors pump through code where "No method X defined for nil object" or something like that.

Thats the kind of thing a good programming language is supposed to help with.

[karussell]

You could introduce (or write more) tests from your side for new feature that you write or for bugs that appear. But in general it takes a bit more experience to get unit testing into existing code, but not undoable and you could practise this for a smaller, independent or even hobby project. Still, the critical part is to get support, not just acceptance, from your boss as sometimes "less problems later" argument does not convince them as "it always worked well without tests".

And just adding tests isn't the only thing it takes to improve the software quality.