Timeline for When mocking a class in a unit test, how should I handle dependency classes that have multiple similar get methods?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 4, 2022 at 15:55 | comment | added | nvoigt | Well, since I need automated integration tests anyway, debugging one when it fails is really zero effort. Not going to write all that mocking code hard-wiring my program to a specific implementation. Test the interface. The interface is the outermost, public layer. Everything behing it is an implementation detail, that is supposed to change due to refactorings. | |
| Sep 4, 2022 at 15:23 | comment | added | krazune | @nvoigt The value of the unit tests here is that if a test fails, the issue is more localized. If a test that doesn't use mocks fails, it's not as obvious which one of the components failed. I think both types of tests are useful. | |
| Sep 4, 2022 at 15:06 | comment | added | nvoigt | @krazune Well, call it as you like. Using a unit test framework, running automated tests, I prefer to test what actually happens in my program, not some mock. And once I can do that, having additional tests that use mocks is totally pointless. | |
| Sep 4, 2022 at 11:51 | comment | added | krazune | @nvoigt You can test how real components work together in integration tests. At the unit testing level, I think that you should mock dependencies so that their behavior doesn't influence the unit that you are testing. I'm not saying we should use a mocking framework for Strings, or Lists, or even BufferedReaders as in my example, but if your unit test breaks, it should break because something in the unit you are testing is broken, or its implementation changed (assuming that the best way to deal with my original problem is tying the test to the implementation). | |
| Sep 4, 2022 at 11:37 | comment | added | krazune | @DocBrown That's exactly what I'm thinking. I fully understand what Dave is saying, and it makes sense, but those comments are focusing too much on my simple example. This problem would still happen if we had a more complex class that had multiple ways to getting data. You would still not know what methods to mock, without tying your unit test to the implementation. | |
| Sep 4, 2022 at 6:43 | comment | added | nvoigt | @krazune If you are asking whether I use a mocking framework, then the answer is no. I have found it utterly useless and a crutch for people unwilling to think what they actually want to test. In the end, their tests are riddled with mocks to a point where they actually just test whether the mocks work. If you are asking whether I substitute dependencies in my tests for other classes implementing the same interface, then yes. I do. But not as often as you (or people using mocks) would think. For example I use an in-memory database and I have a switch to use a real one on demand. | |
| Sep 4, 2022 at 6:19 | comment | added | Doc Brown | Sorry, but I think this answer is missing the point. In this specific case, the class to be mocked can be replaced by some in-memory version, that's true, because the Java standard lib provides such a mechanism. But when we have to deal with something like a (slow) database reader, or network reader, or some other 3rd party class, with a very broad public API and no chance to use a "real" variant, then this suggestion does not work. | |
| Sep 4, 2022 at 4:29 | comment | added | casablanca | +1 as I also think mocking BufferedReader is not a good idea. @krazune I wrote a separate answer detailing when/how I would use mocks. | |
| Sep 4, 2022 at 1:42 | comment | added | Dave Cousineau | @krazune It also allows you to generate 'fake' data to work against. For the example of a BufferedReader, you might still use one, but base it on a MemoryStream instead of a FileStream for example. Then you can feed it any string you want without needing to create a text file. (Example only... BufferedReader is I guess Java which I don't know offhand; not sure how you would set it up so that the reader read from a string.) | |
| Sep 4, 2022 at 1:42 | comment | added | Dave Cousineau | @krazune I'm not a huge expert, but I think a mock should be replacing something external or heavy. when code would normally reach out to a DB, or the network, or a file, the mock keeps everything in memory while otherwise behaving as much like normal as possible. | |
| Sep 2, 2022 at 17:20 | comment | added | krazune | Do you use mocks? In what scenarios do you use them? Here I used a simple BufferedReader, with very simple logic, but it could be a more complex object. | |
| Sep 2, 2022 at 16:23 | history | answered | nvoigt | CC BY-SA 4.0 |