{"id":1048,"date":"2018-12-22T09:00:28","date_gmt":"2018-12-22T09:00:28","guid":{"rendered":"http:\/\/talentedtester.com\/?p=1048"},"modified":"2019-11-07T16:13:41","modified_gmt":"2019-11-07T16:13:41","slug":"integration-testing-vs-unit-testing","status":"publish","type":"post","link":"http:\/\/talentedtester.com\/integration-testing-vs-unit-testing\/","title":{"rendered":"Integration Testing vs Unit Testing – Whats the Difference?"},"content":{"rendered":"
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.<\/p>\n
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.<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n There are two main types of integrations testing: Incremental and non-incremental<\/strong><\/em>. Firstly we will focus on Incremental. With incremental the developer will test out integrations earlier in the development process.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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”.<\/p>\n This way you can test “Brackets” function without waiting for the other modules being ready to test.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\nWhat is a Unit Test?<\/h2>\n
What is an Integration Test?<\/h2>\n
What are the types of Integration test?<\/h2>\n
Types of Incremental Integration Approaches<\/h3>\n
The Top-Down Method<\/h4>\n
The Bottom Up Method<\/h4>\n
All in One Go or “Big Bang” Approach<\/h2>\n
When is integration testing performed?<\/h2>\n