4 ms·

> I also avoid mock objects like the plague, aggressively preferring to either build the interface to be testable in the first place, or failing that, adding so

> I also avoid mock objects like the plague, aggressively preferring to either build the interface to be testable in the first place, or failing that, adding some hooks in the tested code itself, rather than trying to push it onto the code from the outside. Perhaps that's the difference... basically I tend to run my testing one level above the bottom layer on the real-as-possible code, rather than right on the bottom layer of the code with various fake bits attached. I'm not sure I understand this. How do you deal with things that write files out or communicate with other processes? That's where I've found mocks to be of the biggest advantage.

j_baker 17y ago
I would argue that this type of code in most cases isn't a good candidate for unit testing. Typically, dependency-heavy code is better tested via integration tests. The problem with mocking that I've run into is that you're not really testing expected functionality. You're testing that code calls an API. This sounds good in theory until you need to change the API. Then, you have a whole bunch of tests to clean up.
- brown9-2 17y ago
  I prefer to think of it as testing how you code behaves when the API returns x, y, or z. It can be a pain to change the mocks and tests when the API changes, but what else can you do - not test this layer of your code?
  - j_baker 17y ago
    Just because you don't unit test something doesn't mean you can't test it. This is what integration tests exist for.
jerf 17y ago
"How do you deal with things that write files out or communicate with other processes?" I have the tested code write the files out, then I have the test code examine the files. I have the tested code communicate with the other processes, then examine the results, possibly querying the other processes to see whether they got what they should get and did what they should do. I make it so it's easy to put the files in a temporary location, easy to start up test processes for the test to communicate with, and then test the system at this higher level. I am aware that this is counter to the unit testing dogma. I am aware this requires certain amounts of access to the code of all parts of the system, but I usually either have it or make it a priority to get it. So far, the predictions of doom if I do this have failed to manifest. And I've learned that when someone predicts doom that fails to manifest, that's usually because the predictions are based on untested theories and not actual experience. This happens to an absolutely shocking degree in our industry; the amount of software design dogma that is basically just one guy with a PhD's opinion he stated in a paper once 20 years ago, followed by a huge game of telephone, can hardly be understated. (Your homework exercise, if you don't believe this, is to find the published, peer-reviewed paper in which it was determined that unit tests work best if they only test the smallest possible units. Good luck. If that doesn't float your boat, pick your favorite bit of OO-design dogma, like the Law of Demeter, and trace back where it came from. Even good ideas generally don't have the sort of actual support you might think from how far the ideas tend to spread. My take-away from that is that not only is it OK to question, it is a necessity.) Everywhere your test code tests something other than the actual code is a place where bugs can hide. Mock objects are basically a systematic way for providing those places for bugs to hide. I agree with silentbicycle that they have a small place, but IMHO systematic use of them is wrong.

j_baker 17y ago

I would argue that this type of code in most cases isn't a good candidate for unit testing. Typically, dependency-heavy code is better tested via integration tests. The problem with mocking that I've run into is that you're not really testing expected functionality. You're testing that code calls an API. This sounds good in theory until you need to change the API. Then, you have a whole bunch of tests to clean up.

brown9-2 17y ago
I prefer to think of it as testing how you code behaves when the API returns x, y, or z. It can be a pain to change the mocks and tests when the API changes, but what else can you do - not test this layer of your code?
- j_baker 17y ago
  Just because you don't unit test something doesn't mean you can't test it. This is what integration tests exist for.

jerf 17y ago

"How do you deal with things that write files out or communicate with other processes?" I have the tested code write the files out, then I have the test code examine the files. I have the tested code communicate with the other processes, then examine the results, possibly querying the other processes to see whether they got what they should get and did what they should do. I make it so it's easy to put the files in a temporary location, easy to start up test processes for the test to communicate with, and then test the system at this higher level. I am aware that this is counter to the unit testing dogma. I am aware this requires certain amounts of access to the code of all parts of the system, but I usually either have it or make it a priority to get it. So far, the predictions of doom if I do this have failed to manifest. And I've learned that when someone predicts doom that fails to manifest, that's usually because the predictions are based on untested theories and not actual experience. This happens to an absolutely shocking degree in our industry; the amount of software design dogma that is basically just one guy with a PhD's opinion he stated in a paper once 20 years ago, followed by a huge game of telephone, can hardly be understated. (Your homework exercise, if you don't believe this, is to find the published, peer-reviewed paper in which it was determined that unit tests work best if they only test the smallest possible units. Good luck. If that doesn't float your boat, pick your favorite bit of OO-design dogma, like the Law of Demeter, and trace back where it came from. Even good ideas generally don't have the sort of actual support you might think from how far the ideas tend to spread. My take-away from that is that not only is it OK to question, it is a necessity.) Everywhere your test code tests something other than the actual code is a place where bugs can hide. Mock objects are basically a systematic way for providing those places for bugs to hide. I agree with silentbicycle that they have a small place, but IMHO systematic use of them is wrong.