3 ms·

What you are arguing for is that code should be loosely coupled. I generally agree with this (although, like DRY, its validity is context sensitive and one can

What you are arguing for is that code should be loosely coupled. I generally agree with this (although, like DRY, its validity is context sensitive and one can take this approach too far). This is an orthogonal question to whether code should be tested realistically or not, however. You want to test your code against real external inputs for additional realism as well as mocks that are as realistic as possible to isolate the external inputs and remove a potential source of test instability.

bonesss 9y ago
> ...You want to test your code against real external inputs for additional realism as well as mocks that are as realistic as possible... Ding ding: it's not either/or, it's both/and across a spectrum from dumb to smart to dumb again. If you use a google rest API in something serious you want to be able to model the error conditions of that API, you also need to verify the current status and content of that API, you also need to verify your apps behaviour separately for both cases. Loose coupling and DI are important to strike the right balance, but fundamentally you're either testing your solution or you're not.
- crdoconnor 9y ago
  >Ding ding: it's not either/or, it's both Yes, that was the point I was making. >Loose coupling and DI are important to strike the right balance DI is useful sometimes (e.g. when you have a set of modules you want to hotswap with one another), but it's often just an overused crutch to deal with the inability of unit tests to couple to real things - like an actual REST API endpoints over a loopback interface. The whole idea that unit tests drive "good code" by making you DI all the things is a pile of shit. Unit tests just make it painful to not do DI because unit tests are themselves a form of tight coupling.

3 ms·

What you are arguing for is that code should be loosely coupled. I generally agree with this (although, like DRY, its validity is context sensitive and one can

by crdoconnor 9y ago

bonesss 9y ago
> ...You want to test your code against real external inputs for additional realism as well as mocks that are as realistic as possible... Ding ding: it's not either/or, it's both/and across a spectrum from dumb to smart to dumb again. If you use a google rest API in something serious you want to be able to model the error conditions of that API, you also need to verify the current status and content of that API, you also need to verify your apps behaviour separately for both cases. Loose coupling and DI are important to strike the right balance, but fundamentally you're either testing your solution or you're not.
- crdoconnor 9y ago
  >Ding ding: it's not either/or, it's both Yes, that was the point I was making. >Loose coupling and DI are important to strike the right balance DI is useful sometimes (e.g. when you have a set of modules you want to hotswap with one another), but it's often just an overused crutch to deal with the inability of unit tests to couple to real things - like an actual REST API endpoints over a loopback interface. The whole idea that unit tests drive "good code" by making you DI all the things is a pile of shit. Unit tests just make it painful to not do DI because unit tests are themselves a form of tight coupling.