amalcon 3 days ago

I've found exactly three places where I really want to have a mock available:

1) Databases and other persistent storage. Though in this case, the best mock for a database is generally another (smaller, easily snapshottable) database, not something like googlemock.

2) Network and other places where the hardware really matters. Sometimes, I really want to drop a particular message, to exercise some property of the sender. This is often possible to code around in greenfield projects, but in existing code it can be much simpler to just mock the network out.

3) Cases where I am calling out to some external black-box. Sometimes it's impractical to replicate the entire black-box in my test. This could be e.g. because it is a piece of specialized hardware, or it's non-deterministic in a way that I'd prefer my test not to be. I don't want to actually call out to an external black-box (hygiene), so some kind of a mock is more or less necessary.

1
eddautomates 3 days ago

For 1 have you looked at test containers?

amalcon 3 days ago

Briefly, but frankly: copying small SQLite files around works so well in almost all cases that I don't feel the need for a new abstraction.