5 ms·

You're totally right. But think about a blob storage class that has two methods, ReadOneFile(), ReadMultipleFiles(). You have one test that just mocks ReadOne

by andix 6y ago

You're totally right. But think about a blob storage class that has two methods, ReadOneFile(), ReadMultipleFiles(). You have one test that just mocks ReadOneFile(string fileName) and doesn't mock the ReadMultipleFiles(). You now change the implementation of the System Under Test (SUT) to use once the ReadMultipleFile(string[] fileNames) call instead of three times the ReadOneFile(). Now your test fails, but the implementation of the SUT is perfectly valid. You need to rewrite your test. If you would use a fake, the test would stay green, without changing. The test with the fake is less specific to the implementation, and helps you better with refactoring/changing your code. And additionally in this example ReadOneFile() is called three times, and is expected to return three different results. So even your mock needs some logic to handle that.

silveroriole 6y ago
Yes, good point, that’s true. Personally, I know it’s not the ‘right’ ethos, but I see the mock test failure as a bit of a bonus. My change intended to stop calling ReadOne and start calling ReadMultiple. Having to change the test sure tells me I accomplished that! But you’re right that if I’m intending to only test behaviour, the fake lets me do that better. Interesting post, thank you :)
- chunkyfunky 6y ago
  Somewhat tangential to the conversation at hand, but I feel part of the problem here is having two methods i.e. ReadOne/ReadAll. Why not just embrace OOP and go with one method (Read) that takes a specification which itself encapsulates the set of files you want to read? Then it works for none, one, and all files...and makes the argument about Mocking vs Faking somewhat moot; the mock is a simple "for any args return this" and the fake is just as simple. I guess my point is that if you have to agonise over mock vs fake then really it's a sign that your design is not quite as testable as you might like :)

by andix 6y ago

silveroriole 6y ago

Yes, good point, that’s true. Personally, I know it’s not the ‘right’ ethos, but I see the mock test failure as a bit of a bonus. My change intended to stop calling ReadOne and start calling ReadMultiple. Having to change the test sure tells me I accomplished that! But you’re right that if I’m intending to only test behaviour, the fake lets me do that better. Interesting post, thank you :)

chunkyfunky 6y ago
Somewhat tangential to the conversation at hand, but I feel part of the problem here is having two methods i.e. ReadOne/ReadAll. Why not just embrace OOP and go with one method (Read) that takes a specification which itself encapsulates the set of files you want to read? Then it works for none, one, and all files...and makes the argument about Mocking vs Faking somewhat moot; the mock is a simple "for any args return this" and the fake is just as simple. I guess my point is that if you have to agonise over mock vs fake then really it's a sign that your design is not quite as testable as you might like :)