Back in 2011 a couple of posts here on our blog were focusing on the key differences between unit testing and integration testing. We thought now would be a great time to revisit this question, which comes up time and time again. In case you missed the original posts, you can check them out – The Difference Between Unit Testing and Integration Testing, and come right back to this post where we’ll break it down as simply as possible. Ready? Great, read on…
Unit Testing Defined
At its core, unit testing is a type of test to check if an individual small piece of code is doing what it is supposed to do. Sounds simple enough, right?
Unit tests are narrow in scope, they should be easy to write and execute, and their effectiveness depends on what the programmer considers to be useful. These minor, individual tests are intended for the use of the programmer, and are not directly useful to anybody else. Done right, and they can significantly cut down on fixing bugs in the later development stages.
Part of being a unit test is the implication that things outside the code under test are mocked or stubbed out. Unit tests shouldn’t have dependencies on outside systems, and that’s where the lines between unit testing and integration testing get blurred. Unit test focuses on internal consistency as opposed to proving that they play nicely with outside systems.
Actually “integration test” gets used for a wide variety of things, from full-on system tests against an environment made to resemble production to any test that uses a resource (like a database or queue) that isn’t mocked out.
Integration Testing Defined
In comparison to unit test, Integration testing is a type of testing to check if different pieces of the modules work together as a whole.
In other words, integration tests cover the whole application, and they require much more effort to test effectively. They usually require resources like database instances and hardware to be allocated for them.
Integration Testing Methods
There are two fundamental ways of carrying out an integration test. The bottom-up method and the top-down method.
Bottom-up integration typically testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules or builds.
Alternatively, the top-down integration testing approach begins with the highest-level modules being tested first and progressively lower-level modules are tested afterwards. In a comprehensive software development environment, bottom-up testing is usually done first, followed by top-down testing. The process concludes with multiple tests of the complete application, preferably in scenarios designed to mimic those it will encounter in customers’ computers, systems and networks.
Bringing it All Together
Proper and consistent code testing ensures software that is a lot more effective at delivering the correct solution in a predictable and managed way. One of the biggest fears that programmers encounter is changing a piece of code without truly knowing what is going to break. Having a complete unit testing solution allows programmers to remove the fear of the unknown. Both unit testing and integration testing should never be left as an afterthought, but instead should always be an integral part of the development process.
