UNIT TESTING:

Unit testing is a type of software testing where individual units or

components of a software are tested. The purpose is to validate that
each unit of the software code performs as expected. Unit Testing is
done during the development (coding phase) of an application by
the developers. Unit Tests isolate a section of code and verify its
correctness. A unit may be an individual function, method,
procedure, module, or object.

In SDLC, STLC, V Model, Unit testing is first level of testing done

before integration testing. Unit testing is a WhiteBox testing
technique that is usually performed by the developer. Though, in a
practical world due to time crunch or reluctance of developers to
tests, QA engineers also do unit testing.

EXAMPLE OF UNIT TESTING:

Unit testing relies on mock objects being created to test sections of

code that are not yet part of a complete application. Mock objects fill
in for the missing parts of the program.

For example, you might have a function that needs variables or

objects that are not created yet. In unit testing, those will be
accounted for in the form of mock objects created solely for the
purpose of the unit testing done on that section of code.

FUNCTIONAL TESTING:

FUNCTIONAL TESTING is a type of software testing that validates

the software system against the functional
requirements/specifications. The purpose of Functional tests is to
test each function of the software application, by providing
appropriate input, verifying the output against the Functional
requirements.

Functional testing mainly involves black box testing and it is not

concerned about the source code of the application. This testing
checks User Interface, APIs, Database, Security, Client/Server
communication and other functionality of the Application Under
Test. The testing can be done either manually or using automation.
 INTEGRATION TESTING:

Integration testing is performed to test individual components

to check how they function together. In other words, it is
performed to test the modules which are working fine
individually and do not show bugs when integrated. It is the
most common functional testing type and performed
as automated testing.
Generally, developers build different modules of the
system/software simultaneously and don’t focus on others.
They perform extensive black and white box functional
verification, commonly known as unit tests, on the individual
modules. Integration tests cause data and operational
commands to flow between modules which means that they
have to act as parts of a whole system rather than individual
components. This typically uncovers issues with UI operations,
data formats, operation timing, API calls, and database access
and user interface operation.

Let’s take an example of another project of search functionality

in the e-commerce site where it shows the results based on the
text entered by users. The complete search function works
when developers build the following four modules.
Module #1: This is the search box visible to users where they
can enter text and click the search button.
Module #2: It’s a converter or in simple terms program which
converts entered text into XML.
Module #3: This is called Engine module which sends XML
data to the database.
Module #4: Database

In our scenario, the data entered in the search function (module

#1) gets converted into XML by module #2. The EN
module(module #3) reads the resultant XML file generated by
module 2 and extracts the SQL from it and queries into the
database. The EN module also receives the result set and
converts it into an XML file and returns it back to the UI module
which converts the results in user readable form and displays it.
So where does Integration testing comes into the picture?
Well, testing whether the information/data is flowing correctly
or not will be your integration testing, which in this case would
be validating the XML files. Are the XML files generated
correctly? Do they have the correct data? Has the data been
transferred correctly from one module to another? All these
things will be tested as part of Integration testing.
Checking of data transfers between two components is called
as an Interface Testing. It is a part of integration testing.
 REGRESSION TESTING:

Whenever developers change or modify the

functionality/feature, there’s a huge possibility that these
updates may cause unexpected behaviors. Regression testing
is performed to make sure that a change or addition hasn’t
broken any of the existing functionality. Its purpose is to find
bugs that may have been accidentally introduced into the
existing build and to ensure that previously removed bugs
continue to stay dead. There are many functional testing
tools available which support regression testing.

Let’s understand it by continuing our example of the leave

management system. Let’s assume that developers have built
a new feature(build 2) which shows the report of the
employee’s leave history. Now, testers need to test this new
feature by performing smoke testing with new test cases. Now,
testers need to perform regression testing on build 2(Leave
reports) to ensure that the code carried over from Build 1
(Leave application) behaves correctly. Here the main principle
is reusing tests derived from Build 1. Also, the test case for
build 2 would be a subset of build 1.
Regression testing can become a challenge for the testers as
well. Here are some of the reasons:

1. The Number of test cases in the regression suite

increases with each new feature.
2. Sometimes, the execution of the entire regression test
suite becomes difficult due to time and budget constraints.
3. Minimizing the test suite while achieving maximum test
coverage is not a cake walk.
4. Determination of frequency of Regression Tests after
every modification or every build update or after a bunch
of bug fixes is always a challenge