A unit test checks a certain feature of the software. When it fails, you usually know exactly where to look for a place to fix the problem. They are short, compact and fast.
They come at a cost, though: You have to replicate the setup code in your test.
This is an important point. To use a feature of your software, you always have some set up to do. This set up has to exist in your production code. For unit tests, you will have to copy some parts of this code into your tests because usually, the setup of the production code simply isn’t fine grained or flexible enough to be useful for tests. Think tests which check the error handling: Your production code usually can’t build mock objects that raise errors when certain methods are being invoked.
An integration test reuses the production configuration. It tests many features at once, in the same order and with the same or at least a very similar environment that your final application will use. They are high level and often much easier to set up. But that comes at a cost:
- They are slow
- When they fail, there will be many places which could cause the issue, so fixing them is more expensive
- They break more often because you have more dependencies
- Setting up a test for the “success” scenario will be simple but injecting mock objects to cause exact error states will be much harder
So be aware what kind of test you’re writing.
Tagged: Integration testing, Software, Test, Testing, Unit testing Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
