Chapter 8 - Boundaries
- We can and should keep third party code abstracted so we have control over which properties and methods are accessible
- We should create tests for third-party code so we create a better understanding of it and how we can use it on our application. This would also make us sure that if these libraries update in the future, that portion we are using in our code did not broke.
^ I don't think this is very practical, most libraries are not that easy to write relevant tests on. I can see why this is good and will try to do this in a future project but I am not optimistic.
- When writing code that will integrate with code that doesn't yet exists and have no interface, we can create a class that has the interface we wish we had to mock that integration. Once we have the real code, we can adapt this class and abstract the implementation of the newly written module.
Top comments (0)