ppt unit testing software engineering

1. UNIT TESTING
Software Engineering –II
Instructor: Zainab Mahmood

2. INTRODUCTION
• Black Box testers don’t care about Unit Testing. Their main goal is to validate the
application against the requirements without going into the implementation details.
• But as a curiosity or Out of the box thinking, have you ever wondered how
developers test their code? What method do they use to test before releasing code
for testing? How is dev-testing important in an agile process? The answer to all this
is Unit Testing.

3. WHAT IS UNIT TESTING?
• Unit Testing is not a new concept. It’s been there since the early days of
programming. Usually, developers and sometimes White box testers write Unit tests
to improve code quality by verifying every unit of the code used to implement
functional requirements ( test drove development TDD or test-first development).
• Most of us might know the classic definition –
“Unit Testing is the method of verifying the smallest piece of testable code against
its purpose.” If the purpose or requirement failed then the unit test has failed.
• In simple words, it means – writing a piece of code (unit) to verify the code (unit)
test written for implementing requirements.

4. WHAT IS UNIT TESTING?
• In Unit testing small functions and modules of the project are tested.
• This type of testing is performed by developers before the setup is handed over to
the testing team to formally execute the test cases.
• Unit testing is performed by the respective developers on the individual units of
source code assigned areas. The developers use test data that is different from the
test data of the quality assurance team.
• The goal of unit testing is to isolate each part of the program and show that
individual parts are correct in terms of requirements and functionality.

5. UNIT TESTING IN SDLC

6. UNIT TESTING IN SDLC
• In Unit testing, developers use manual or automated tests to ensure that each unit
in the software meets the customer’s requirement. This unit can be an individual
function, object, method, procedure, or module in the software under test.
• Writing unit tests to test the individual units makes writing comprehensive tests
easier as all the units are put together. During software development, it is done as
the first level of testing.

7. IMPORTANCE OF WRITING UNIT
TESTS
• Unit Testing is used to design robust software components that help maintain code
and eliminate the issues in code units. We all know the importance of finding and
fixing defects in the early stage of the software development cycle. This testing
serves the same purpose.
• It is an integral part of the agile software development process. When a nightly build
run unit test suite should run and report should be generated. If any of the unit tests
have failed then the QA team should not accept that build for verification.

8. IMPORTANCE OF WRITING UNIT
TESTS
• If we set this as a standard process, many defects would be caught in the early
development cycle, saving much testing time.
• Many developers hate to write unit tests. They either ignore or write bad unit test
cases due to tight scheduled or lack of seriousness (yea they write empty unit tests,
so 100% of them pass successfully ;-)). It’s important to write good unit tests or
don’t write them at all. It’s even more important to provide sufficient time and a
supportive environment for real benefit

9. UNIT TESTING METHODS
• It can be performed in 2 ways :
1.Manual Testing
2.Automated Testing

10. UNIT TESTING METHODS
• In Manual Testing, the tester manually executes test cases without using any
automation tool. Here, each stage of the test is executed manually. Manual Testing
is tedious especially for tests that are repetitive and requires more effort to create
and execute test cases. Manual Testing does not require knowledge of any testing
tool.
• It is a fact that 100% of Automation is not possible and thus there will always be
some level of manual testing performed.
• In Automated Testing, software testing automation tools are used to automate the
tests/test cases. The automation tool can record and save your test and it can be
re-played as many times as needed without any further human intervention.
• These tools can even enter test data into the system being tested as well as it can
compare the expected results to the actual results and automatically generate the
reports. However, the initial cost of setting up test automation tools is high.

11. TECHNIQUES WITHIN UNIT
TESTING
• #1) White box testing:
• In white-box testing, the tester knows the
internal structure of the software including
the code and can test it against the design
and the requirements. Hence white box
testing is also known as transparent
testing.

12. TECHNIQUES WITHIN UNIT
TESTING
• #2) Black box testing:
• In black-box testing, the tester does not
know the internal structures either the code
of the software.

13. TECHNIQUES WITHIN UNIT
TESTING
• #3) Grey box testing:
• This is also referred to as a semi-
transparent technique testing which
means, the testers are only partially
aware of the internal structure, functions,
and designs along with the requirements.
Debugging is done by actual input from the
front-end to get exact data in the back-end.
The grey box is therefore considered as a
combination of black box and white box
testing techniques.

14. TECHNIQUES WITHIN UNIT
TESTING
• #3) Grey box testing:
• Grey box testing covers the following
types of testing:
• Matrix Testing.
• Pattern Testing.
• Orthogonal Pattern Testing.
• Regression Testing.

15. UNIT TESTING CYCLE

16. WHAT MAKES A GOOD UNIT
TEST?
• How to write good Unit Tests?
• A Unit test should be written to verify a single unit of code and not the integration.
• Small and isolated Unit tests with clear naming would make it very easy to write and
maintain.
• Changing another part of the software should not affect the Unit test if those are
isolated and written for a specific unit of code.
• It should run quickly
• A Unit test should be reusable

17. UNIT TESTING FRAMEWORKS
• Unit Testing frameworks are mostly used to help write unit tests quickly and easily.
Most of the programming languages do not support unit testing with the inbuilt
compiler. Third-party open source and commercial tools can be used to make unit
testing even more fun.
• List of popular Unit Testing tools for different programming languages:
1.Java framework – JUnit
2.PHP framework – PHPUnit
3.C++ frameworks – UnitTest++ and Google C++
4..NET framework – NUnit
5.Python framework – py.test

18. MISCONCEPTIONS AND TRUTHS
• It takes more time to write code with Unit test cases, and we don’t have time for that
– In reality, it would save your development time in the long run.
• Unit testing will find all bugs – It won’t, as the intent of the Unit test is not to find
bugs but develop robust software components that will have fewer defects in later
stages of SDLC.
• 100% code coverage means 100% test coverage – This does not guarantee that
code is error-free.

19. HOW TO ACCEPT UNIT TESTING?
• Good unit testing can be carried out in 3 basic parts.
1.Write the unit test code
2.Run the unit test code to check if it meets the system requirement
3.Execute the software code to test for any defects and whether the code meets the
system requirement.
• After undertaking the above 3 steps, if the code appears to be correct then the unit
test is said to be passed. And if it does not meet the system requirements, the test
fails. In this case, the developer needs to recheck and correct the code.

20. BEST PRACTICE
• To create the best code during this testing, consider the below points:
• Code should be strong: There are instances where the test fails or in worst cases
does not get executed at all if the code is broken.
• Understandable and reasonable: The code should be easy to understand. This
makes it easy for the developer to write the code and even other developers who
will work on the code subsequently will find it easy to debug.
• Should be the single case: Tests that defines multiple cases in one, are complex
to work with. Thus writing a single case code is best practice, which makes the code
easier to understand and debug.

21. BEST PRACTICE
• Other points to be kept in mind are as follows:
• Instead of creating test cases for all the conditions, focus on the test that affects the
behavior of the system.
• There are chances of the bug reoccurrence due to the browser’s cache.
• Test cases should not be interdependent.
• Pay attention to the loop condition also.
• Plan the test cases more frequently.

22. CHALLENGES WITH UNIT
TESTING:
• Though Unit Testing is useful, there are some challenges to perform it. Some of
them are listed below
• The trouble with Test Names
• Writing wrong test types
• Understanding the entire code is tedious
• Need to test doubles
• Lack of proper initial conditions
• Finding dependencies

23. WHITE BOX TESTING TECHNIQUES
• Statement Coverage
• Decision Coverage
• Branch Coverage
• Condition Coverage
• Multiple Condition Coverage
• Finite State Machine Coverage
• Path Coverage
• Control flow testing
• Data flow testing

24. BLACK BOX TESTING TECHNIQUES
• Equivalence Class Testing: It is used to minimize the number of possible
test cases to an optimum level while maintains reasonable test coverage.
• Boundary Value Testing: Boundary value testing is focused on the values at
boundaries. This technique determines whether a certain range of values
are acceptable by the system or not. It is very useful in reducing the number
of test cases. It is most suitable for the systems where an input is within
certain ranges.
• Decision Table Testing: A decision table puts causes and their effects in a
matrix. There is a unique combination in each column.

25. WHITE BOX TESTING TECHNIQUES

26. COVERAGE
• White Box Testing is coverage of the specification in the code:
• 1. Code coverage
• 2. Segment coverage: Ensure that each code statement is executed once.
• 3. Branch Coverage or Node Testing: Coverage of each code branch in from all possible
was.
• 4. Compound Condition Coverage: For multiple conditions test each condition with
multiple paths and combination of the different path to reach that condition.
• 5. Basis Path Testing: Each independent path in the code is taken for testing.
• 6. Data Flow Testing (DFT): In this approach you track the specific variables through each
possible calculation, thus defining the set of intermediate paths through the code.DFT tends
to reflect dependencies but it is mainly through sequences of data manipulation. In short,
each data variable is tracked and its use is verified. This approach tends to uncover bugs
like variables used but not initialize, or declared but not used, and so on.
• 7. Path Testing: Path testing is where all possible paths through the code are defined and
covered. It’s a time-consuming task.
• 8. Loop Testing: These strategies relate to testing single loops, concatenated loops, and
nested loops. Independent and dependent code loops and values are tested by this
approach.

27. WHY WE PERFORM WBT?
• To ensure:
• That all independent paths within a module have been exercised at least once.
• All logical decisions verified on their true and false values.
• All loops executed at their boundaries and within their operational bounds internal
data structures validity.

28. WHY WE PERFORM WBT?
• To discover the following types of bugs:
• Logical error tend to creep into our work when we design and implement functions,
conditions or controls that are out of the program
• The design errors due to difference between logical flow of the program and the
actual implementation
• Typographical errors and syntax checking

30. STEPS TO PERFORM WBT
• Step #1 – Understand the functionality of an application through its source code.
Which means that a tester must be well versed with the programming language and
the other tools as well techniques used to develop the software.
• Step #2– Create the tests and execute them.
• When we discuss the concept of testing, “coverage” is considered to be the most
important factor

31. STATEMENT COVERAGE
• In a programming language, a statement is nothing but the line of code or
instruction for the computer to understand and act accordingly. A statement
becomes an executable statement when it gets compiled and converted into the
object code and performs the action when the program is in a running mode.
• Hence “Statement Coverage”, as the name itself suggests, it is the method of
validating whether each and every line of the code is executed at least once.

32. BRANCH COVERAGE
• “Branch” in a programming language is like the “IF statements”. An IF statement has
two branches: True and False.
• So in Branch coverage (also called Decision coverage), we validate whether each
branch is executed at least once.
• In case of an “IF statement”, there will be two test conditions:
• One to validate the true branch and,
• Other to validate the false branch.
• Hence, in theory, Branch Coverage is a testing method which is when executed
ensures that each and every branch from each decision point is executed

33. PATH COVERAGE
• Path coverage tests all the paths of the program.
• This is a comprehensive technique which ensures that all the paths of the program
are traversed at least once. Path Coverage is even more powerful than Branch
coverage.
• This technique is useful for testing the complex programs.

34. WHITE BOX TESTING EXAMPLE
• Consider the below simple
pseudocode:
• Statement Coverage – we would
only need one test case to check all
the lines of the code.
• That means:
• If I consider TestCase_01 to be
(A=40 and B=70), then all the lines
of code will be executed.
• Now the question arises:
1.Is that sufficient?
2.What if I consider my Test case as
A=33 and B=45?

35. WHITE BOX TESTING EXAMPLE
• Consider the below simple
pseudocode:
• Hence for maximum coverage, we
need to consider “Branch
Coverage”, which will evaluate the
“FALSE” conditions.

36. WHITE BOX TESTING EXAMPLE
• Consider the below simple
pseudocode:
• So for Branch coverage, we would require two
test cases to complete the testing of this
pseudo code.
• TestCase_01: A=33, B=45
• TestCase_02: A=25, B=30
• With this, we can see that each and every line
of the code is executed at least once.
• Here are the Conclusions that are derived
so far:
• Branch Coverage ensures more coverage than
Statement coverage.
• Branch coverage is more powerful than
Statement coverage.
• 100% Branch coverage itself means 100%
statement coverage.
• But 100 % statement coverage does not
guarantee 100% branch coverage.
• .

37. WHITE BOX TESTING EXAMPLE
• Consider the below simple
pseudocode:
• path Coverage:
• As said earlier, Path coverage is
used to test the complex code
snippets, which basically involve
loop statements or combination of
loops and decision statements.

38. WHITE BOX TESTING EXAMPLE
• Consider the below simple
pseudocode:
• path Coverage:
• Now to ensure maximum coverage,
we would require 4 test cases.
• How? Simply – there are 2 decision
statements, so for each decision
statement, we would need two
branches to test. One for true and
the other for the false condition. So
for 2 decision statements, we would
require 2 test cases to test the true
side and 2 test cases to test the
false side, which makes a total of 4
test cases.

40. PATH COVERAGE
• In order to have the full coverage, we would need following test cases:
• TestCase_01: A=50, B=60
• TestCase_02: A=55, B=40
• TestCase_03: A=40, B=65
• TestCase_04: A=30, B=30

41. PATH COVERAGE
• Red Line – TestCase_01 = (A=50,
B=60)
• Blue Line = TestCase_02 = (A=55,
B=40)
• Orange Line = TestCase_03 = (A=40,
B=65)
• Green Line = TestCase_04 = (A=30,
B=30)

42. JAVA SCRIPT UNIT TESTING
• Jest Tutorial - JavaScript Unit Testing Using Jest Framework
(softwaretestinghelp.com)