3 ms·

> Tests that perform network operations [...] ban these This means banning integration tests of most interesting services. IMO you don't want to do that.

newjersey 5y ago
Now I am far from an expert on monorepos but I want to know what you think of the next sentence: > The first one is easy, ban these. You don’t need them in the blocking portion of your pipelines. I don't think they mean ban integration testing. I think they are saying don't block merge requests on integration testing. Is this still a problem? Perhaps they are doing some kind of trade off management. Isn't that basically what engineering is, like I remember when I was in high school the classic problem of engineering was do you want thicker heavier wires on electricity poles which means more poles and more expensive or thinner lighter wires so they are lighter but higher resistance and more "leakage". My understanding is there are no correct answers, only the least bad ones. Imagine someone trying to change the background color of a button in css and waiting three hours for integration tests to finish before anyone can +2 it.
neurotrace 5y ago
I'd argue that you should have thorough unit tests for each service to ensure that they always respect their public API. Additionally, in a monorepo you can share type definitions so regardless of the service, you know for sure that you're using the right API. If all of that is in place then you can test the integration by just mocking out those services rather than testing their API n times. If you're in an environment where you have limited/absence of type checking then you're right. In my experience, most problems that come from the integration of networked services come from not properly accounting for all possible responses. You're expecting to get a 200 response and a field of `x` but you got a 204 so the response is empty. That sort of thing.
- Spivak 5y ago
  This is easy when you own all the code, it's a god damn nightmare the moment you introduce code that isn't yours like Redis, Postgres, Elasticsearch, every cloud API. If you're assuming that the hundreds of millions of lines of other people's code totally outside your control always follows its spec, doesn't have bugs, or can change out from under you with no version bump (yay cloud) you're gonna be bit hard and then have to invest in integration tests.
  - neurotrace 5y ago
    Good point. I have always run integration tests with Postgres etc. and have found value in it. I do think that you should have a substantially smaller set of those sorts of tests though.

newjersey 5y ago

Now I am far from an expert on monorepos but I want to know what you think of the next sentence: > The first one is easy, ban these. You don’t need them in the blocking portion of your pipelines. I don't think they mean ban integration testing. I think they are saying don't block merge requests on integration testing. Is this still a problem? Perhaps they are doing some kind of trade off management. Isn't that basically what engineering is, like I remember when I was in high school the classic problem of engineering was do you want thicker heavier wires on electricity poles which means more poles and more expensive or thinner lighter wires so they are lighter but higher resistance and more "leakage". My understanding is there are no correct answers, only the least bad ones. Imagine someone trying to change the background color of a button in css and waiting three hours for integration tests to finish before anyone can +2 it.

neurotrace 5y ago

I'd argue that you should have thorough unit tests for each service to ensure that they always respect their public API. Additionally, in a monorepo you can share type definitions so regardless of the service, you know for sure that you're using the right API. If all of that is in place then you can test the integration by just mocking out those services rather than testing their API n times. If you're in an environment where you have limited/absence of type checking then you're right. In my experience, most problems that come from the integration of networked services come from not properly accounting for all possible responses. You're expecting to get a 200 response and a field of `x` but you got a 204 so the response is empty. That sort of thing.

Spivak 5y ago
This is easy when you own all the code, it's a god damn nightmare the moment you introduce code that isn't yours like Redis, Postgres, Elasticsearch, every cloud API. If you're assuming that the hundreds of millions of lines of other people's code totally outside your control always follows its spec, doesn't have bugs, or can change out from under you with no version bump (yay cloud) you're gonna be bit hard and then have to invest in integration tests.
- neurotrace 5y ago
  Good point. I have always run integration tests with Postgres etc. and have found value in it. I do think that you should have a substantially smaller set of those sorts of tests though.