<<Clean Code>> Quotes: 8 Boundaries
Using Third-Party Code
There is a natrual tension between the prvider of an interface and the user of an interface. Providers of third-party packages and frameworks strive for board applicability so they can work in many environment and appeal to a wide audience. Users, on the other hand, want an interface that is focused on their particular needs. This tension can cause problems at the boundaries of our systems.
Exploring and Learning Boundaries
It’s not our job to test the third-party code, but it may be in our best interest to write tests for the third-party code we use.
Instead of experimenting and trying out the new stuff in our production code, we could write some tests to explore our understanding of the third-party code.
Learning Tests Are Better Than Free
The learning tests were precise experiments that helped increase our understanding.
Not only are learning tests free, they have a positive return on investment.
Learning tests verify that the third-party packages we are using work the way we expect them to.
Whether you need the learning provided by the learning tests or not, a clean boundary should be supported by a set of outbound tests that exercise the interface the same way the production code does.
Using Code That Does Not Yet Exist
here is another kind of boundary, one that separates the known from the unknown.
This design also gives us a very conveniont seam in the code for testing.
