from Hacker News

Ask HN: Writing unit test mocks vs. real dependencies?

by kamalkishor1991 on 10/21/20, 4:01 PM with 8 comments

• by dragontamer on 10/21/20, 4:56 PM

  If A depends on B depends on C, then:

  * C should have a unit test proving its capabilities.

  * B is allowed to have a unit test that depends on C (because C's unit tests prove its correctness).

  * A is allowed to have a unit test that depends on B (similar to the B/C case).

  ---------

  It seems like mocking was a way to "cut" the dependency between A and C. In particular, you usually get huge "dependency chains" between your code base. A depends on B, depending on C, depending on D... depnds on E, F, G, H, I... etc. etc. Pulling in all of this code for a unit test seems backwards. IMO, the solution isn't to use mocking, but to refactor your code to reduce the dependencies.

  But if the code is outside of your control (ie: owned by another team, or even a 3rd party), maybe mocking is the best option.

  "Flattening" your code dependencies, reducing the "height" of your layers will simplify your code logic and software engineering. But its not always an option in reality.

  ------

  If you have a circular dependency: A depends on B and B depends on A, then:

  1. Find a way to break the circular dependence. Invent a new class C: Maybe A depends on C, B depends on C, and C represents the shared interface between the two. Once broken up in this manner, A depends on C (and A unit tests depend on C), then B depends on C (and B unit tests depend on C), and finally you write unit tests for C itself. No mocking needed.

  2. If #1 cannot happen, Both A and B must be unit tested together as a singular component. Trying to split it up using mocking is a fool's errand.

• by Jugurtha on 10/23/20, 1:12 PM

  Well, I had to use mocks when interacting with a device through Bluetooth Low Energy. It's a hardware device that can't be in a CI/CD pipeline.

  I pushed the hardware part into a class, injected it as a dependency to client code so I could materialize the BLE connection whenever I wanted.

  The binary encoding/decoding wasn't tied to the class and was handled by a codec I wrote to decouple packet handling from the device. You only had to feed it a YAML file I wrote to model the device communication protocole. I read the manufacturer's specs and came up with a schema for rx/tx padding, etc.

  When we changed devices, we just had to give another YAML file to the codec and the code worked.

  All this to say that it was really hard to test before code refactoring and loosening the dependency on the actual device.

  Once we had a nice interface, you could write a MockBLEDevice class even by inheriting from the real class, just changing the actual BLE connection to return something else and keeping everything else the same.

• by seanwilson on 10/21/20, 6:31 PM

  There's no best way and time is a limited resource. Weigh up the time it's going to take and the pros/cons for your specific project. If you've done this and think mocking is going to take up too much time for not enough benefit then you've made a good tradeoff.

• by goatcode on 10/21/20, 5:07 PM

  Test what you are testing. Are you testing a method or function? Mock its inputs. If your test of a function fails because an API or a database is not available, that's approaching an integration test. If there's a question of whether there are too many mocks being used, the dev may not have thought out a testing strategy well enough. Be certain of what you're testing.

  That's what I usually go by.