If you are new to testing the different types of testing can be confusing. During my career I have done unit testing as a developer, but primarily system and integration testing as a tester. Today we are going to focus on Unit and Integration testing in particular.
What’s the difference between integration testing & unit testing? Unit testing is typically performed by developers and focusses on one particular function or code module. Integration testing focusses on the communication of one or many code modules or functions to prove that the inputs and outputs work as designed.
A unit test, or white box test as it is also known, is typically done by developers. An entire application consists of many individual cod modules or functions. Typically this is created by a team of developers working together on a tight timeline.
Each developer is responsible for testing that their allocated code module meets the expected design. For example, if the application was a calculator. One developer might work on the addition function and another on multiplication.
The developer working on the addition function would need to prove that this function worked in isolation, before it is integrated into the “calculator” application.
If we extend the calculator example above. An integration test, in this context, would prove that the calculator application modules talk to each other. This testing is typically done by test analysts and can also be referred to as Black box testing.
The reason for this name “Black Box”, is because the tester does not need to have intricate knowledge of the individual code module, they just need to insure the modules talk to each other and the “calculator” application hangs together.
There are two main types of integrations testing: Incremental and non-incremental. Firstly we will focus on Incremental. With incremental the developer will test out integrations earlier in the development process.
This is done by using stubs and drivers to simulate inputs and outputs for incomplete code modules. The most important advantage is that issues can be identified very early. This will in turn reduce costs by delivering a more quality product to the dedicated Test analysts.
Within the Incremental integration approach, there are two variations: “Top-Down” and “Bottom-Up”. Both of these types are named after the flow of the testing.
In the Top-down method, if you can picture a pyramid split up into different levels. This defines the functionality, with the main function at the top, and the minor functionality at the bottom.
With the Top-Down approach, you start with the top level code modules and substitute the lower level modules with stubs to prove they work ahead of time.
What is a stub? A stub is placeholder program that will take an expected input and output an expected result. This allows the developer to code a function and test its inputs and outputs work, before the actual module intended to integrate is ready.
E.g. You have an application called calculator, and within this application you have a function called brackets, addition and subtraction. The brackets function works out the calculation when you have addition and subtraction in brackets.
However, to test the “Brackets” function you need addition and subtraction ready. So, to gut around this problem, you use a “Stub” called “addition” and another one called “subtraction”.
This way you can test “Brackets” function without waiting for the other modules being ready to test.
As you can imagine, this is opposite to the Top-Down method. In this method, the lower level code modules are completed and tested without the parent or higher level modules being available.
For this to be possible drivers are used are used to provide the necessary inputs. One of the biggest disadvantages of this method is the order of the development. Unfortunately because the priority high level code modules are developed last, there could be major issues with these key inputs down the line.
The incremental model is preferred because you can gradually bring in each nodule and deal with issues in manageable chunks. However, if it is unclear exactly how these modules will communicate you can use the “Big-Bang” approach.
Effectively taking a number of modules and integrating them all in one go and seeing what happens. As you can imagine it very rarely works straight away and is likely to be a panful process.
The biggest issue is identifying exactly what module is at fault when the integration fails. The large amount of integrations can make the process very complex.
Integration testing (click here to see who typically does Integration Testing) is performed after Unit testing but before UAT. In my experience of testing a System testing phase tends to happen first to prove the main system is functioning correctly, then integrations are tested after.
When Is Unit Testing Performed? Unit testing is performed after each module of code is developed. The idea is to improve the quality of code that is delivered to the system testers.
Stubs and drivers can be used in the absence of other required code modules. For example, if a developer was creating a “brackets” function in a calculator app. He may be waiting for the other “Multiply” and “addition” code modules to be complete, before he can unit test his function.
Instead of waiting he can use stubs and drivers to provide the expected inputs/outputs to prove that his function works, once the other modules are complete.
Can JUnit be used for integration testing? The short answer is yes, it can be used. But it depends on what you want to test with it. Essentially it is not the ideal job for this task, but you can adapt it to work for some integration tasks.
What is a Black Box Test? A black box test is basically a method of testing that does not require the tester to see or understand the inner workings of the code functions. For example a System test phase may have a selection of functional tests.
The tester does not need to know how to code to run the test, in fact they just need to know the expected result from a successful functional test.
What is a White Box Test? As appose to Black box, this test expects you to have knowledge of the inner workings of the code function. Unit testing is an example of White box testing. With this level of testing you are expected to understand the code level inputs and outputs required to complete the test.