duct 2018-10-31 | Slack Archive

ccann15:10:23

> 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

weavejester15:10:39

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

weavejester15:10:09

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.

weavejester15:10:41

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.

ccann15:10:40

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

ccann15:10:16

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

weavejester15:10:46

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

weavejester15:10:09

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

ccann15:10:40

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

weavejester15:10:01

2018-10-31

Channels