Do Not Unit Test Third Party Frameworks
I'm stealing today's tip from Brendan Enrick. He has written a series of blog posts on tips for unit testing. In one of them, he talks about unit testing with third party frameworks:
Make sure that what you're testing is part of your code and not someone else's. If you're testing code you have no access to you better not be keeping that around as an automated test. You're wasting your time if you're creating automated tests for this code. If you find a bug in the code you can tell someone about it, but you probably can't fix the code. If it is an open source project you're testing then go test the code in their test library and fix issues you find. You will be doing them and yourself a favor. Don't clutter your own test library.
You can checkout the rest of that post here. At the bottom you'll see links to other posts he's done on the topic.
Beware of letting your unit tests become integration tests
Today's tip comes from Dustin Sparks. As soon as you have a test dependent on something other than the unit of code you're testing, or a mock, you might have an integration test. That's ok, just be aware you're doing it.
Unit tests are designed to execute very quickly, on a single unit of code. Once you introduce dependencies you typically slow them down. That makes people less likely to run them. Also, unit tests should be focused. It's feedback on your test design. If you're trying to write a unit test, and you get an integration test, you might be having an issue framing the problem space.
