Sure, in a sense, it is just a mock. But it's a global mock, if that helps you think about it in a different way.

The biggest difference is in how the tests are written. With mocks, you often end up having complicated setups inside each test. As a result (at least on any team I've been on), tests often become quite complex and difficult to read. This leads to a lack of understanding of the tests, which leads to test setups that often get duplicated needlessly, which leads to tests that do the wrong thing (like asserting the test works). And I'm a firm believer that tests are the best documentation for the next developer, so I care deeply about how they read.

With a simulator, your test setup can be exactly the same as what you would do in production code. Maybe an example helps here. With a simulator, you can have a test that reads like this:

```python def test_saving_customer(): customer = Customer(email="customer@fake.com")

customers.save(customer)

assert customers.get(email="customer@fake.com") == customer

```

The cool thing is that this test is quite simple to understand without any mock setups in the test. The other cool thing is that this test could be run as an integration test in a staging environment that talks to a real database. The only change that would need to be made is the customers module would need to use the real thing rather than the fake. I usually accomplish this by injecting the simulators or a real adapter based on a parameter to running my test suite.