duct

ccann 2018-10-31T15:48:23.023500Z

> Tests that use a real external service, for example a database, are often slow and difficult to run concurrently. Slow tests that need to be run in serial mean you can test fewer scenarios in a test run. Testing against real services is important to ensure your tests are accurate, but fast, concurrent tests are needed to maximise the number of test cases. Boundaries allow you to do both. You can test the implementation of a boundary against a real service, but the rest of your tests can use a mock instead. How do boundaries allow you to do both? It looks to me like the happy path is testing against mocks, not real services like a database. The last sentence seems key but I don’t see how it follows

2018-10-31T15:50:39.024Z

You can test the logic of your system with mocks, but you still need to ensure your boundaries work correctly.

2018-10-31T15:51:09.024200Z

For example, you might have a create-user method on a boundary protocol. You could test this against a real database to ensure it creates the records you expect.

2018-10-31T15:51:41.024400Z

Once you're happy that the method behaves as it should, you can then substitute it for a mock for the rest of your tests.

ccann 2018-10-31T15:52:40.024600Z

ah okay so you mean test as in with the REPL to check the implementation and then capture that interaction with a mock

ccann 2018-10-31T15:53:16.024800Z

doesn’t that introduce the chance that the implementation breaks but the test against the mock doesn’t?

2018-10-31T15:54:46.025Z

I mean write tests for your boundary using a real implementation, and use mocks for all other tests that use your boundary.

2018-10-31T15:55:09.025200Z

You can test with the REPL as well, but that's not what I meant.

ccann 2018-10-31T15:56:40.025400Z

ah okay, got it. thanks for helping me understand!

2018-10-31T15:57:01.025600Z

np