Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

Listen to me. This is very, very important. Just do the tests anyway. Don't put them in the same repo, do them through the API, and don't go overboard, but for people that scream about needing things yesterday are obviously poor planners, poor planners change their minds frequently and this requires a test suite to keep up with.

View on HN

You make tests for your own stuff, but 15 other engineers don't make tests. You have partial test coverage and it just becomes overwhelming because 15 people can write more code lines than you can.

You can't do everyone's job. Trying to write tests for the whole team (in addition to your own work) will just exhaust you. But doing tests on your just own code is still better than no one doing it. Better yet, see if you can use it as a tool to convince others and recruit them to your side.

"Better yet, see if you can use it as a tool to convince others and recruit them to your side."

Been there, tried that. I make it as easy as "run this bat file to test everything" in this specific sub-project. And then I watch them make some silly little "test-program" to debug the thing. Not only that, but we discuss a feature in said sub-project that they're implement and I hear disturbing comments such as "I hope it works" or "I hope it all still works after I'm done".

That's the point where you need to ask yourself if you're doing yourself any favors working on a project with 15 other engineers who don't even write unit tests. Go find a better project and/or company.

The poor planners are in charge. Usually if you're going to build tests, you'll be doing it on your own time. That's where the 60+ hour work weeks come from.

If you're not going to build tests, you'll spend 4x in debug sessions and also get "fear of change". I worked in a project where we had 80%+ branches coverage in unit tests and awesome automated regression package for end-to-end. When you have that, you have a luxury to be lazy in predictions what would break if I fix this. 90% of defect were business-related, not stability or functionality issues.

It entirely depends on the culture. In my career I've worked in test centric environments, and I've worked in places were testing was nearly forbidden. You can guess which ones generally run smoother. Some places just really care about cranking code out the door, and the people in charge don't realize how badly they're shooting themselves in the feet. It's more common than you'd think.

But I agree with everything you're saying, which is why I try to get into more test centric cultures when job hunting.

Reply on news.ycombinator.com