3 ms·
Using interfaces (whether literal interfaces in your language or the general concept) to isolate operations that rely on dependencies is so critical IMO. It mak
by jjice 3y ago
Using interfaces (whether literal interfaces in your language or the general concept) to isolate operations that rely on dependencies is so critical IMO. It makes testing so much easier, takes little additional upfront effort, and generally makes nicer to read code (subjectively).
For example, if I have my `MailSender` interface with an `SMTPMailSender` implementation but then I want to switch over to using the AWS SDK for interacting with SES for auth purposes, I can just implement my interface as always and create my new `SESMailSender` and plop it in place and all my code just works. This isn't just for testability, but also general modularity.
It takes so little additional upfront effort as well. Even just declaring an interface helps you isolate what functionality should actually be publicly exposed. I really don't think this creates any serious development drag. On top, it makes your tests so much easier to write, and tests are usually a good bang for your buck for the major cases.
If you truly only need a single implementation and not even the ability to have one for testing, then that's fine! Keeping in mind that adapting this to an interface in the future should be simple and do that when it comes up.
- gbacon 3y agoCombine that with the abstract test pattern, and teaching your harness how to instantiate an instance of a new concrete implementation is often all that’s necessary.