←back to thread

An overly aggressive mock can work fine, but break much later

(nedbatchelder.com)
67 points ingve | 3 comments | 16 Nov 25 22:36 UTC | HN request time: 1.153s | source
Show context
BoiledCabbage ◴[17 Nov 25 03:10 UTC] No.45950554[source]▶
The mock discussion still misses the real solution, which is to refactor the code so that you have a function that simple reads the file and returns json that is essentially a wrapper around open and doesn't need to be tested.

Then have your main function take in that json as a parameter (or class wrapping that json).

Then your code becomes the ideal code. Stateless and with no interaction with the outside world. Then it's trivial to test just like and other function that is simple inputs translated outputs (ie pure).

Every time you see the need for a mock, you're first thought should be "how can I take the 90% or 95% of this function that is pure and pull it out, and separate the impure portion (side effects and/or stateful) that now has almost no logic or complexity left in it and push it to the boundary of my codebase?"

Then the complex pure part you test the heck out of, and the stateful/side effectful impure part becomes barely a wrapper over system APIs.

replies(10): >>45950831 #>>45950929 #>>45951112 #>>45952380 #>>45952963 #>>45954934 #>>45958404 #>>45958469 #>>45960148 #>>45960154 #
1. jeroenhd ◴[17 Nov 25 12:19 UTC] No.45952963[source]▶
The risk to that approach is that you end up writing code that cannot deal with the real world problems of I/O, such as timeouts, failed reads, jitter, and other weird behaviour.

Separating I/O from logic makes a lot of sense and makes tests much easier to write and code much easier to reason about, but you'll still need to implement some sort of mocking interface if you want to catch I/O problems.

replies(1): >>45953834 #
2. mejutoco ◴[17 Nov 25 14:26 UTC] No.45953834[source]▶
> how can I take the 90% or 95% of this function that is pure and pull it out, and separate the impure portion (side effects and/or stateful) that now has almost no logic or complexity left in it

They addressed this concern already. These are not contradicting approaches.

replies(1): >>45955523 #
3. SAI_Peregrinus ◴[17 Nov 25 17:03 UTC] No.45955523[source]▶
I think the disconnect is that the impure portion often has substantial amounts of inherent complexity. If you're working at a high level that's handled by a lower level (OS, framework, etc.) but somebody is writing that framework or OS or HAL. And they need to test too, and ultimately someone is going to have to make a test double of the hardware interface unless all testing is going to require hardware-in-the-loop.