As an aside,think about unit testing from the start.
Ideally before your fingers start touching the keyboard. It's possible to write code that is well-designed, efficient, effective, performant, basically good solid code that you can be proud of, that nonetheless is borderline impossible to add wide-coverage unit tests to afterwards.
If "at least 80% of functions/classes/lines-of-code/whatever are exercised by unit tests" is a requirement, be sure to think about that from the start so that your design doesn't render it impossible.
I have recently got a new job and they require unit tests everywhere, such that it will cover at least 80% of the codebase.
Presumably, this means that they already have unit tests for existing code, and therefore are already using test frameworks.
I strongly advise to go with whatever your company is already using, rather than branching out on your own and finding something different. That will make it easier for those you work with to work on your code, and vice versa, and also means that there will be examples for you to look at already to learn from, as well as people who already have knowledge and experience if you need help.
On the off-chance that this is a brand new requirement, that is being placed on you and no-one else, I can second the reccommendation for Catch (and Fakeit for mocks). I've had good experiences with Google Test and Google Mock, too.