3rd-party code still needs tests
I'm not the first to say it but it needs re-stating. 3rd-party libraries are no guarantee that your code continues to behave as expected.
If one of the duties of your work is making sure you're not introducing bloat or cruft or inefficiencies or bugs or unexpected behavior, then you're cutting corners if you don't have tests, whether you use 3rd-party code or not.
"Maintaining tests" may seem like an expense to those who don't, can't or won't, but it is naive to claim that writing tests means "it takes longer to develop" or "you'll have to maintain tests along with source."
It might take longer to develop from scratch but it will take less effort to modify or refactor later - when you'll need to maintain pace. Your requirements will change, your code will have to change - why not plan for that up front?
It is in fact cheaper - and healthier - to maintain test suites that actually run and report failures, than to debug and patch (and therefore involve QA who have other things to focus on too), or to maintain documentation that goes stale with each commit.
jQuery 1.8.0, released in 2012, broke the 'create element' fork (wouldn't parse attributes in the html string). We were using the googleapis CDN and changed the version settings in our configs to pull in the new version. Once the bugs came in, we had to dig that out. Though it was great to figure out the cause (yay, someone else did it, not us), it did take significant time, it wasn't readily debuggable without tests - and I could have been doing other things, which is the selling point of 3rd-party code.
By relying on 3rd-party code without actively encouraging tests, you're reducing your ability to maintain pace later - and reducing your technical team to glue coders.
In the words of Alan Cooper, you're creating a culture of hacking and rushing. Maintaining tests helps you maintain pace.
Test-driven or test-at-the-same-time-as development is not a miracle cure, it is medicine - stay healthy!