4 ms·

I think this is an article about writing tests. Some code the author depended on changed the behavior of their app, while they were focused on releasing a crit

I think this is an article about writing tests. Some code the author depended on changed the behavior of their app, while they were focused on releasing a critical fix. They deployed the critical fix and noticed the change way too late in the process, thus wasting an entire workday getting it fixed. Well, that's what tests are for -- so that when some person you don't know edits a dependency, they get a message "you can't check this in until you debug this code you are affecting". Maybe you don't need that for your one-person weekend project, but at a company with tens of thousands of developers working in the same repository, it can sure prevent a lot of problems.

anothernewdude 5y ago
Some guy who updates the dependency isn't fixing your tests. They're breaking whatever and not caring.
- Jensson 5y ago
  If they break your tests at Google then you just roll back their code. After you've done that a few times they will fix your code or learn not to break your tests. This isn't hostile, this is what the coding guidelines tells you to do, if someone broke your tests you roll it back.
  - jrockway 5y ago
    Yup, exactly. I used to do third-party reviews at Google and people pretty much always ran the presubmit tests and the upgrade CLs had the dependent changes and approvals from those owners. I never encountered any breakage dramas (only people mad that they couldn't add a new programming language to google3); people were generally excellent citizens even though there was no "be an excellent citizen to get promoted" carrot around. (Hell, I did the third-party reviews out of the goodness of my heart, and I doubt any promo committee ever said "hey, we hate jrockway's project work and peer feedback, but he did rubber stamp that upgrade to foobarbaz so let's promote him".) Things have probably changed since I left, but I bet the author's experience is pretty rare these days too. Google's system works quite well for their scale.
- deleted 5y ago
  [deleted]

anothernewdude 5y ago

Some guy who updates the dependency isn't fixing your tests. They're breaking whatever and not caring.

Jensson 5y ago
If they break your tests at Google then you just roll back their code. After you've done that a few times they will fix your code or learn not to break your tests. This isn't hostile, this is what the coding guidelines tells you to do, if someone broke your tests you roll it back.
- jrockway 5y ago
  Yup, exactly. I used to do third-party reviews at Google and people pretty much always ran the presubmit tests and the upgrade CLs had the dependent changes and approvals from those owners. I never encountered any breakage dramas (only people mad that they couldn't add a new programming language to google3); people were generally excellent citizens even though there was no "be an excellent citizen to get promoted" carrot around. (Hell, I did the third-party reviews out of the goodness of my heart, and I doubt any promo committee ever said "hey, we hate jrockway's project work and peer feedback, but he did rubber stamp that upgrade to foobarbaz so let's promote him".) Things have probably changed since I left, but I bet the author's experience is pretty rare these days too. Google's system works quite well for their scale.
deleted 5y ago
[deleted]