I just published an early relese of my Simulated.FileSystem library. This library makes it easier to separate platform concerns out of my models. It works really well with a hexagonal architecture.
This library will define a set of ports for common external dependencies, with multiple adapters for each port. The initial release just includes a file system port, with two adapters: native file system and in-memory file system. Continue reading “New Simulators Library”
I recently posted an entry about replacing mocks with Simulators. That one used a Simulator from my running example code. Here’s another example, which may make the concept more clear.
This is a file system simulator. I’m building it out as a generic simulator, re-usable across projects. Right now, I’m using it Continue reading “Simulating the File System”
One of the common uses for mocks is to replace expensive or stateful components, such as file systems, networks, GUIs, and databases.
However, I also see a cluster of other problems that arise at interfaces with these types of components, especially when they are system-level services:
- Primitive obsession. Rarely are these APIs written as methods on an abstract object that return other abstractions. Instead, people pass around a lot of strings & things, which become arguments for static methods.
- State. Partly because there isn’t a place to put it, state tracking becomes a mess. For example, you want to ask a web service for something. Are you logged in? Do you have to do something if you aren’t?
- Lack of encapsulation. Those static methods end up everywhere. And often they end up with duplicate patterns everywhere (e.g., check for login before each call).
- The API does not feel natural to the application. It doesn’t follow the project’s idioms, and doesn’t just flow into place.
For this reason, I use an entirely different sort of test double: a system simulator. And often these simulators stop being test doubles Continue reading “Mock Free Example, part 2: Simulators”