2. Confusion between Unit Testing and Integration Testing
For someone looking to start a career in software testing, you might have came
across terms such as Unit Testing and Integration Testing. You would have wondered
what is the difference between the two.
In Software Development Lifecycle, a software is developed by many developers who
work on individual modules. These modules are then integrated into a full-fledged
software. The testing specific to these modules and the integrated software is what is called
Unit and Integration Testing respectively.
rockinterview.in
3. What is Unit Testing?
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.
A Unit Test is -
Repeatable: You can rerun the same test as many times as you want.
Consistent: Every time you run it, you get the same result.
In Memory: It has no “hard” dependencies on anything not in memory (such as file system,
databases, network)
Fast: It should take less than half a second to run a unit test.
Checking one single concern or “use case” in the system
rockinterview.in
4. What is Integration Testing?
Integration testing is a type of testing to check if different pieces of the modules work
together as a whole.
An Integration Test might -
Use system dependent values that change dynamically (such as DateTime.Now, or
Environment.MachineName)
Create objects of which it has little control (such as threads, random number
generators)
Reach out to external systems or local machine dependencies (from calling web
services to using local configuration files)
Test multiple things in the course of one test case (from database integrity to
configurations, to protocols, to system logic; all in one go).
rockinterview.in
5. Two Methods for Integration Testing
Bottom-up integration testing typically
begins with unit testing, followed by
tests of progressively higher-level
combinations of units called modules
or builds.
The top-down integration testing
begins with the highest-level modules
being tested first and progressively
lower-level modules are tested
afterwards.
Bottom-up Method Top-down Method
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.
rockinterview.in
6. Differences between Unit Testing and Integration Testing
The objective of Unit Testing is to test
each part of the program to make sure
that the individual parts are working
correctly.
Checks a single component of an
applications.
The scope of unit testing is narrow and
focuses on a small piece of code.
Unit testing only test the functionality of
individual units and may not catch
integration or system wide errors.
The objective of Integration Testing is
to combine modules in the
application and test if they work
together as a group.
The behavior of integration module is
considered in integration testing.
The scope of integration testing is
broad and puts the whole application
under test.
Integration Testing uncovers errors
that occur when integrating individual
modules into the overall system.
Unit Testing Integration Testing
rockinterview.in
7. Differences between Unit Testing and Integration Testing
It can be performed any time and
doesn’t have any dependencies.
Unit Tests shouldn’t have any
dependencies on outside systems.
It starts with module specification.
Pays attention to the behavior of single
modules.
Requires detailed visibility of the code.
It is usually carried out after Unit
Testing and before System
Testing
Integration Tests depends on outside
systems like Database, Hardware,
etc.
It starts with interface specification.
Pays attention to integration among
modules.
Requires detailed visibility of the
integration structure.
Unit Testing Integration Testing
rockinterview.in
8. Differences between Unit Testing and Integration Testing
It is usually executed by developers.
It is easy to find errors.
It is not further sub divided into
different types.
Unit tests are easy to write and
execute.
It is a kind of white box testing.
It is usually executed by a testing
team.
It is relatively difficult to find errors.
It is further sub divided into top-down,
bottom-up integration testing and so
on
Integration tests require much more
effort to write and test effectively.
It comes under both black box and
white box testing.
Unit Testing Integration Testing
rockinterview.in
9. Conclusion
Testing is a way to ensure that the software developed delivers on the objectives in a
predictable manner.
Unit and Integration Testing are equally important to verify the working on individual
modules as well as the overall system. Therefore, Unit and Integration Testing should
be an integral part of the development process.
rockinterview.in
10. BLACKBOX AND WHITEBOX TESTING
Prepared By:
Mr. Surya Prakash Pandey
Awadhesh Pratap Singh Uniersity,
Rewa(M.P.)
11. BLACKBOX TESTING
� In Black Box Testing we just focus on inputs and
output of the software system without bothering
about internal knowledge of the software program.
[Figure of Blackbox Testing]
� The above Black Box executable program can be any
software system you want to test.
12. BLACKBOX TESTING
� By applying black-box techniques, you derive a set of
test cases that satisfy the following criteria:
� (1) test cases that reduce, by a count that is greater
than one the number of additional test cases that must
be designed to achieve reasonable testing, and
� (2) test cases that tell you something about the
presence or absence of classes of errors, rather than
an error associated only with the specific test at hand.
13. BLACKBOX TESTING
� Blackbox Techniques/ Methods:
⚫ Equivalence partitioning: It is a software test design
technique that involves dividing input values into
valid and invalid partitions and selecting
representative values from each partition as test data.
⚫ Boundary Value Analysis: It is a software test design
technique that involves determination of boundaries
for input values and selecting values that are at the
boundaries and just inside/ outside of the boundaries
as test data.
⚫ Cause effect graphing: It is a software test design
technique that involves identifying the cases (input
conditions) and effects (output conditions), producing
a Cause-Effect Graph, and generating test cases
accordingly.
14. WHITEBOX TESTING:
� White Box Testing (also known as Clear Box Testing,
Open Box Testing, Glass Box Testing, Transparent Box
Testing, Code-Based Testing or Structural Testing) is
a software testing method in which the internal
structure/ design/ implementation of the item being
tested is known to the tester.
� White Box Testing is like the work of a mechanic who
examines the engine to see why the car is not moving.
� Using white-box testing methods, you can derive test
cases that
� (1) guarantee that all independent paths within a
module have been exercised at least once
15. � (2) exercise all logical decisions on their true and
false sides
� (3) execute all loops at their boundaries and within
their operational bounds
� (4) exercise internal data structures to ensure their
validity.
WHITEBOX TESTING:
17. WHITEBOX TESTING:
Why and When White-Box Testing:
� White box testing is mainly used for detecting logical
errors in the program code.
� It is used for debugging a code, finding random
typographical errors, and uncovering incorrect
programming assumptions.
� White box testing is done at low level design and
implementable code.
� It can be applied at all levels of system development
especially Unit, system and integration testing.
� White box testing can be used for other development
artifacts like requirements analysis, designing and test
cases.
18. WHITEBOX TESTING:
Whitebox Testing Techniques:
� Following are Whitebox testing techniques:
⚫ Statement coverage: This technique is aimed at
exercising all programming statements with minimal
tests.
⚫ Branch and decision coverage: This technique is
running a series of tests to ensure that all branches are
tested at least once.
� Tools: An example of a tool that handles branch
coverage testing for C, C++ and Java applications
is TCAT-PATH
⚫ Path coverage: This technique corresponds to testing
all possible paths which means that each statement
and branch is covered.
