3 ms·

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

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.

JeremyMorgan 12y ago
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.
- sgdread 12y ago
  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.
  - JeremyMorgan 12y ago
    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.
mahyarm 12y ago
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.
- pimlottc 12y ago
  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.
  - zo1 12y ago
    "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".
- kyllo 12y ago
  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.

JeremyMorgan 12y ago

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.

sgdread 12y ago
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.
- JeremyMorgan 12y ago
  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.

mahyarm 12y ago

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.

pimlottc 12y ago
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.
- zo1 12y ago
  "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".
kyllo 12y ago
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.