I’m unit testing a class which has two dependencies, both of which are external packages (I’m using C# so these are NuGet packages, AutoMapper and CompareNETObjects).
(NOTE: Both are just utilities, related to converting an object from one type to another, and to comparing objects. Neither makes any external calls)
Should I mock these external packages or is it acceptable to assume they are robust building blocks that don’t need testing, similar to the .NET libraries?
Or, perhaps, should I decide whether to test each package on a case-by-case basis? Say don’t test popular open source packages as we could assume they’re well tested but do test less popular ones that don’t have as many users or contributers.
I know answers to this question are likely to be opinions but I’d like to find out what experienced unit-testers think.
Mock the externals for your unittests, where applicable
It all depends on what the external library does for you. For example, if you have a class that depends on an external library that works with the file system you probably want to mock that and not perform any actual filesystem operations in your unittest. If you have an external library that does mapping from one object onto another, you’ll probably be fine and would want to use that external library in your unittests directly.
Remember that unittests are about a cohesive unit of code, not a single class.
Have broad integrationtests that cover your external library
If you have external libraries, make sure that your integrationtests cover some cases for them. You want to test your integration with those external libraries as part of your tests.
Contribute to the package if it lacks tests
If you find that the external library you are using lacks tests, do not write those tests in your application. Instead, see if you can write the code and submit it to the maintainer and get it in the official version so others can benefit from it too.