5 ms·

Complexity never comes for free. Running a bunch of services creates all sort of failure modes unrelated to the tests you are running and requires maintenance

Complexity never comes for free. Running a bunch of services creates all sort of failure modes unrelated to the tests you are running and requires maintenance in the long term. Adding docker to it only increases the overall complexity. There are good reasons for doing unit and functional testing with mocks.

hardwaresofton 5y ago
> Complexity never comes for free. A platitude, thanks. > Running a bunch of services creates all sort of failure modes unrelated to the tests you are running and requires maintenance in the long term. Yes, and mocks are not free either -- the more complex the backend system you're dealing with, the more complex your mock of it must be, and that code will be brittle. I specifically said in the case where backing software is simple/easy to spin up, then it makes sense to spin it up. How much of Redis are you going to re-implement to get a mock with good parity that is in the end still missing the quirks of real redis? > Adding docker to it only increases the overall complexity. We are literally discussing a project that runs temporary isolated postgres with an extremely simple single executable experience. It's case-dependent but all you need is a different query string. It's not that hard -- if you think it's that hard to spin up a redis/postgres container on your machine in 2021 then I don't know what to tell you, a lot of things are going to be hard for you. And again, what you want to do instead is write an approximation of postgres in your codebase that will never run anywhere else -- this kind of thing is only easy if it's done for you. As soon as you have a non-trivial interface (let's say one that would do a JOIN in production but you've mocked locally) then you're going to have a hard time writing that mock and maintaining it. > There are good reasons for doing unit and functional testing with mocks. Did I say there weren't? You've eviscerated the strawman you made. Let me restate -- if you're mocking function calls/point-in-time calls with what they're supposed to return then that's fine. However, if you're maintaining a fake approximation of a redis server in your code that isn't a library (i.e. written by someone else), then that is stupid. Just run redis (even without a container). If you find it difficult to run a single extremely easy to administer (in the case of redis) external process (dockerized or not) in your tests, then I don't know what to tell you -- I just hope we never work together.
- ex_amazon_sde 5y ago
  > a lot of things are going to be hard for you The FAANGs that gave me offers seem to think otherwise... > I just hope we never work together Guess I struck a sore spot here.
  - hardwaresofton 5y ago
    > The FAANGs that gave me offers seem to think otherwise... If you judge your capability by which FAANGs give you offers I don't know what to tell you. The only FAANG I personally respect implicitly is Netflix because they have a well documented culture and they basically cast off a ton of their old stuff as open source and you can see how far ahead they are. Still this doesn't mean every engineer at Netflix is a good one or doesn't have things to learn/things they can't do. BTW speaking of FAANGs, Google does their builds and tests with Bazel -- which they invented to suit. Developer tooling is definitely. I don't know where Bazel sits vs linux containers on the complexity scale, but it's certainly not simple. > Guess I struck a sore spot here. Nope I just... honestly mean that, with no particular malice directly at you. I find that when I work with/on teams that have developers that just can't tolerate anything outside their own realm (self professed "frontend" engineers who hate backend/ops/anything else) it really holds everyone back. For example when a small squadron of developers if vehemently against containers just because they can't see the benefits (this was a lot more common ~5 years ago), without having spent time to understand the technology. Creating good UX for those developers is one thing, but the restriction of the solution space to something suboptimal just because people don't understand and choose not to research/understand technology is frustrating to me so it's not a good place for me to work.
weird-eye-issue 5y ago
Using Docker to run the services they mentioned really isn't that complex and hardly requires maintenance. Using Docker Compose you can literally spin up and link those services together in just a few lines of YAML. Not sure what maintenance you are talking about either aside from sometimes bumping the version number.

hardwaresofton 5y ago

> Complexity never comes for free. A platitude, thanks. > Running a bunch of services creates all sort of failure modes unrelated to the tests you are running and requires maintenance in the long term. Yes, and mocks are not free either -- the more complex the backend system you're dealing with, the more complex your mock of it must be, and that code will be brittle. I specifically said in the case where backing software is simple/easy to spin up, then it makes sense to spin it up. How much of Redis are you going to re-implement to get a mock with good parity that is in the end still missing the quirks of real redis? > Adding docker to it only increases the overall complexity. We are literally discussing a project that runs temporary isolated postgres with an extremely simple single executable experience. It's case-dependent but all you need is a different query string. It's not that hard -- if you think it's that hard to spin up a redis/postgres container on your machine in 2021 then I don't know what to tell you, a lot of things are going to be hard for you. And again, what you want to do instead is write an approximation of postgres in your codebase that will never run anywhere else -- this kind of thing is only easy if it's done for you. As soon as you have a non-trivial interface (let's say one that would do a JOIN in production but you've mocked locally) then you're going to have a hard time writing that mock and maintaining it. > There are good reasons for doing unit and functional testing with mocks. Did I say there weren't? You've eviscerated the strawman you made. Let me restate -- if you're mocking function calls/point-in-time calls with what they're supposed to return then that's fine. However, if you're maintaining a fake approximation of a redis server in your code that isn't a library (i.e. written by someone else), then that is stupid. Just run redis (even without a container). If you find it difficult to run a single extremely easy to administer (in the case of redis) external process (dockerized or not) in your tests, then I don't know what to tell you -- I just hope we never work together.

ex_amazon_sde 5y ago
> a lot of things are going to be hard for you The FAANGs that gave me offers seem to think otherwise... > I just hope we never work together Guess I struck a sore spot here.
- hardwaresofton 5y ago
  > The FAANGs that gave me offers seem to think otherwise... If you judge your capability by which FAANGs give you offers I don't know what to tell you. The only FAANG I personally respect implicitly is Netflix because they have a well documented culture and they basically cast off a ton of their old stuff as open source and you can see how far ahead they are. Still this doesn't mean every engineer at Netflix is a good one or doesn't have things to learn/things they can't do. BTW speaking of FAANGs, Google does their builds and tests with Bazel -- which they invented to suit. Developer tooling is definitely. I don't know where Bazel sits vs linux containers on the complexity scale, but it's certainly not simple. > Guess I struck a sore spot here. Nope I just... honestly mean that, with no particular malice directly at you. I find that when I work with/on teams that have developers that just can't tolerate anything outside their own realm (self professed "frontend" engineers who hate backend/ops/anything else) it really holds everyone back. For example when a small squadron of developers if vehemently against containers just because they can't see the benefits (this was a lot more common ~5 years ago), without having spent time to understand the technology. Creating good UX for those developers is one thing, but the restriction of the solution space to something suboptimal just because people don't understand and choose not to research/understand technology is frustrating to me so it's not a good place for me to work.

weird-eye-issue 5y ago

Using Docker to run the services they mentioned really isn't that complex and hardly requires maintenance. Using Docker Compose you can literally spin up and link those services together in just a few lines of YAML. Not sure what maintenance you are talking about either aside from sometimes bumping the version number.