4 ms·

Test in prod is terrible. Write unit and integration tests, test on staging, and then monitor Prod.

by m1117 6y ago

site-packages1 6y ago
Sorry to make the assumption that you didn't read the article, but it really sounds like you didn't and are just making a comment about the headline. I would recommend reading the article.
- m1117 6y ago
  Yes, I think the headline must reflect the content of the article, otherwise it confuses me and make me write false comments and wastes my time.
Nbox9 6y ago
That’s really close to what the article says. It also suggests flexing the feature in Prod, which is a totally valuable thing. The article is mostly about the “Chuck it over the fence” mentality some developers and engineering cultures have about code that has shipped into production.
throwaway894345 6y ago
Advice like this is good for applications that place a high value on stability and quality, which aren't deployed frequently, and which are monolithic (or rather, which are deployed monolithically--microservices that are deployed all at once are less a problem as it pertains to testing). However, the further your application deviates from these invariants, the less good this advice becomes. And there are good reasons to deviate--many applications exist in a business context in which production bugs are often not a very big deal (e.g., social networks); however, the ability to iterate rapidly (especially the ability to test new features, etc rapidly) is paramount. In these contexts, it's entirely appropriate to trade off the ability to test in advance in exchange for the ability to iterate more rapidly--this includes things like moving to a microservice deployment cadence (different components deployed at different times to elide expensive cross-team deployment coordination moments). Microservices are harder to test to the same confidence interval because it's hard to fix the versions of all of the different components in order to assure reproducible tests, and the value of doing so is diminished because in practice any given combination of versions is likely short-lived since one or more components will be redeployed in a matter of hours or even minutes. Of course, unit testing and integration testing are still valuable in these contexts, but they aren't as valuable as they are in other contexts, so testing in prod (coupled with the ability to quickly fix bugs) is necessary to make up the difference. So like everything in software development, "it depends".

Test in prod is terrible. Write unit and integration tests, test on staging, and then monitor Prod.

by m1117 6y ago

Test in prod is terrible. Write unit and integration tests, test on staging, and then monitor Prod.

Sorry to make the assumption that you didn't read the article, but it really sounds like you didn't and are just making a comment about the headline. I would recommend reading the article.

m1117 6y ago
Yes, I think the headline must reflect the content of the article, otherwise it confuses me and make me write false comments and wastes my time.

Nbox9 6y ago

That’s really close to what the article says. It also suggests flexing the feature in Prod, which is a totally valuable thing. The article is mostly about the “Chuck it over the fence” mentality some developers and engineering cultures have about code that has shipped into production.

throwaway894345 6y ago

Advice like this is good for applications that place a high value on stability and quality, which aren't deployed frequently, and which are monolithic (or rather, which are deployed monolithically--microservices that are deployed all at once are less a problem as it pertains to testing). However, the further your application deviates from these invariants, the less good this advice becomes. And there are good reasons to deviate--many applications exist in a business context in which production bugs are often not a very big deal (e.g., social networks); however, the ability to iterate rapidly (especially the ability to test new features, etc rapidly) is paramount. In these contexts, it's entirely appropriate to trade off the ability to test in advance in exchange for the ability to iterate more rapidly--this includes things like moving to a microservice deployment cadence (different components deployed at different times to elide expensive cross-team deployment coordination moments). Microservices are harder to test to the same confidence interval because it's hard to fix the versions of all of the different components in order to assure reproducible tests, and the value of doing so is diminished because in practice any given combination of versions is likely short-lived since one or more components will be redeployed in a matter of hours or even minutes. Of course, unit testing and integration testing are still valuable in these contexts, but they aren't as valuable as they are in other contexts, so testing in prod (coupled with the ability to quickly fix bugs) is necessary to make up the difference. So like everything in software development, "it depends".