[teeray]

> Mocks are static, but reality evolves.

I learned “test your mocks” long ago from Sandi Metz, and that advice has paid off well for me. Have some set of behavioral conformance tests for the kind of thing you expect (e.g. any database worth its salt should be able write and read back the same record). Then stick your mock right under that same battery of tests alongside your implementation(s). If either deviate from the behavior you depend on, you’ll know about it.

[zingar]

Bang on Sandi! I hadn’t heard that quote but she’s my favorite speaker on testing and OO.

Another way of looking at this advice is that every time there’s a mock there needs to be a test that shows that the real code can be used in the same way that the mock is used.

[mzi]

> any database worth its salt should be able write and read back the same record

This excludes a lot of cases, like just a simple postgres where reads are done from a replica.

[teeray]

You're free to come up with a better example. The point is that dependencies have behavioral properties that software depends upon. We can write tests for those behaviors. Mocks that are correct and remain so should implement those same behaviors we expect from the prod implementations of those dependencies.