Testing with ApexMocks vs Stub API

ApexMocks uses the Stub API. The pro of ApexMocks is that you get a ready-to-use Stub API framework for your own tests, while the con would be that it may have a lot of features you don't need (code bloat). If you want, you can take just the parts you need and trim it down, use it as an example for your own in-house framework, or do something else entirely. Either way, you will still be using the Stub API. Use ApexMocks if you are new to the Stub API and don't want to/have time to learn the Stub API, or use the Stub API if you have a different design you'd like to use. There's really not much difference either way, just pick a method and stick with it.

ApexMocks may initially seem daunting but the code bloat argument is not particularly strong compared to the alternatives. Our org uses ApexMocks all the time and it offers many advantages:

1. Our testmethods run way faster because many use cases can be done without having to mock any Sobjects via DML or even to CRUD any SObjects via DML. Note that we also leverage the concepts of the Trailhead Selector, Domain, Service, and Unit of Work layers.
2. The ffLib_Match objects allow for powerful unit testing to verify that you are calling your methods with the arguments you expect to call them with
3. You can mock exceptions in classes and test your exception handling without bending over backwards to create an exception with actual data
4. With argumentCaptors, you can go one step further and verify that methods called with custom ApexTypes are called as you expect
5. You can even count the number of times methods are called versus expectations

Chapter 12 of Force.com Enterprise Architecture goes into detail on how this all works.