Sabourin 507 - 607 Unit Testing

Unit Testing Workshop
Robert Sabourin
President
AmiBug.Com, Inc.
Montreal, Canada
rsabourin@amibug.com
June 21, 2021 © Robert Sabourin, 2005 Slide 1
AmiBug.Com, Inc.
Section 1
Overview and Some Philosophy

AmiBug.Com, Inc.
Unit Testing Concepts
Overview:
– Objective
– Introductions and definitions
– Some Philosophy
– Testing in Development Process
– Lifecycle Models
– Unit Testing Process
– Unit Testing Ideas
– Unit Testing Cost? Benefit?
– Testing Approaches
– Test Cases
– Unit Test Code Coverage
– Organizing Your Unit Testing
– Paradoxes, Problems and Politics
– Final Words
– Test Harness
– Example Unit Test Harness

AmiBug.Com, Inc.
Objective
“The main objective is to make sure

that we leave the delegates with a good
understanding of what Unit testing is
and what they need to do to implement
it. They can then build on this basic
knowledge.”

AmiBug.Com, Inc.
Introduction
• Robert Sabourin ,
Software Evangelist
• President
• AmiBug.Com Inc.
• Montreal, Quebec,
Canada
• rsabourin@amibug.com

AmiBug.Com, Inc.
Some Philosophy
Fundamental Question
• How do you know when you are finished?

AmiBug.Com, Inc.
Some Philosophy
Crosby on Quality
• “Quality is defined as conformance to
requirements”
• “Quality is not a measure of
GOODNESS”
– Phil B. Crosby, Quality is Free

AmiBug.Com, Inc.
Some Philosophy
Deming Quality approach
(PDCA)
• Plan, Do Check, and Act:

Plan what you want to implement.
Do the pilot implementation.
Check the results of the pilot.
Act on the results by tweaking the process
before the next project.

AmiBug.Com, Inc.
Some Philosophy
Edsger W. Dijkstra
• “Program testing can be used to show
the presence of bugs, but never to show
their absence”

AmiBug.Com, Inc.
Some Philosophy
Boris Beizer
• “Why software has bugs – the
fundamental problem – Programming is
a bitch.”
• The Frozen Keyboard - 1986

AmiBug.Com, Inc.
Some Philosophy
Ken Blanchard
• “Feedback is the breakfast of
champions!”

AmiBug.Com, Inc.
Some Philosophy
Watts S. Humphrey
• “… the job of the software
engineer is to deliver high-
quality software products at
agreed cost and schedule …”
• “… even the most
experienced software engineer
injects about one defect for ten
lines of code …”

AmiBug.Com, Inc.
Some Philosophy
Tom DeMarco
• “You cannot control what you cannot measure.”

AmiBug.Com, Inc.
Some Philosophy
C. Northcote Parkinson
Parkinson’s Law:
“…work expands so as to fill the
time available for its
completion…”

AmiBug.Com, Inc.
Some Philosophy
Yoda
"No! Try not, Do. Or do not.

There is no try."

AmiBug.Com, Inc.
Some Philosophy
Steve Covey
“…begin with the end in mind …

“…first things first …"

AmiBug.Com, Inc.
Section 2
About Bugs

AmiBug.Com, Inc.
About Bugs
Bug Defined
• To make our job more fun, whenever
we have a concern with software, we
call it a “bug”.

AmiBug.Com, Inc.
About Bugs
A Bug Vocabulary
Fault, Error
mistake in implementation or design
Failure, Conditions
misbehavior of software due to a fault
Symptom
something observed due to a failure
Bug
anything wrong with the software
Quality
value to someone
Defect
legal term. Something is definitely wrong.
Anomaly, Problem, Issue, Concern, Snag
other terms to use for a bug
AmiBug.Com, Inc.
About Bugs
Software Testing
• It’s all about people! (and the occasional
bug too)

AmiBug.Com, Inc.
Purpose of
Unit Testing
• Common definition:
– To find bugs way before our customers do!
• Broader definitions:
– Provide objective information about the status of
the development task being implemented.
– To assess whether task at hand is finished and the
work product can be used by others
– To confirm a developers work is ready to be
integrated into a system
AmiBug.Com, Inc.
Section 3
Unit Testing in Development

AmiBug.Com, Inc.
Purpose of Unit Testing

So what exactly did they throw over the wall?

AmiBug.Com, Inc.
Testing in
Development Process
• Testing activities take place in all parts of
software development
• From requirement eliciting to final
shipment
• Testing is part of the development
process
• Testing is part of the company business
process
AmiBug.Com, Inc.
Phase
Rational Unified
Inception Elaboration Construction Transition
Process (RUP)
Requirements
Testing can take place as part

Analysis
of each phase of development .
Core Workflow
Design
Development
Testing
Maintenance
AmiBug.Com, Inc.
Phase
Rational Unified
Inception Elaboration Construction Transition
Process (RUP)
core workflow involved in development

Testing can take place as part of each
Requirements
Analysis
Core Workflow
organization.
Design
Development
Testing
Maintenance
AmiBug.Com, Inc.
Lifecycle Models
– Types of development processes

» Waterfall
»V
» Spiral
» Microsoft Solution Framework
» Evolutionary
» Unified Process
» Extreme Programming

AmiBug.Com, Inc.
Waterfall
Development Process

AmiBug.Com, Inc.

AmiBug.Com, Inc.
Spiral Development

AmiBug.Com, Inc.
Microsoft® Solution
Framework - MSF

AmiBug.Com, Inc.
Evolutionary
Development

AmiBug.Com, Inc.
Rational Unified
Process
Phases
Core Workflows Inception Elaboration Construction Transition
Requirements
An iteration in the
elaboration phase
Analysis
Design
Implementation
Test
P re lim ina ry ite r. ite r. ite r. iter. iter. iter. iter.

Ite ra tion (s) #1 #2 #n #n + 1 # n +2 #m #m +1

AmiBug.Com, Inc.
Extreme Programming

AmiBug.Com, Inc.
Characteristics
Traditionally done by developers when modules/units of code are developed.

Testing is done at the end of an assigned unit of work (coding).
Unit Developer completes to confirm - are we finished this task - exit criteria.
Blend of white and black box techniques.
Testing done to at the time when the work of one or more task assignments are combined,
thus the term integration.
Integration Units combine and stubs are included for missing elements of the system.
Grey box.
Testing Phase
The entire system has been integrated together.

Complete functional testing implemented.
System Development team focuses on correcting defects identified in testing process.
Regression testing.
Customer runs his own testing to confirm that the system meets requirements.
Generally acceptance testing plan has been known by System testing team.
Acceptance
Non-intrusive testing of the system while it is in use to measure quality factors such as
performance, system resource use and to spot check correct operation.
Live
AmiBug.Com, Inc.
About Bugs
Bugs are not Good or Bad

AmiBug.Com, Inc.
About Bugs
Some bugs are important

and have a high priority!

AmiBug.Com, Inc.
About Bugs
Some bugs are dangerous

and have a high severity!

AmiBug.Com, Inc.
About Bugs
• Setting the priority and severity of a bug

is a business decision
• Changing business conditions impact
the priority and severity of a bug!

AmiBug.Com, Inc.
Bug Quadrants
Urgent Urgent
Severe Not Severe
Not Urgent Not Urgent

Severe Not Severe

AmiBug.Com, Inc.
Getting Things Done
We have precious little time to run tests!
We must always be prepared!

AmiBug.Com, Inc.
- Who manages them?
- How are they prioritized?
Getting - Where can I find them?

- Are the communicated?
Things Done
- Do they get reprioritized?
- Are business drivers known?
- Are technical risks known?
REQ BUG
Development FLOW
FLOW
- Who manages them? - Are builds delivered?

- What are they? - Where do developers work?
- Where can I find them? - Configuration management?
- When are they updated? - Source control? Baseline?
- Why are they changing? - Transition? Periodic?
- How are they evolving?
Release - Smoke tests?
- Do we observe turbulence? Cycle - Owners:Dev IT DBA SQA?
AmiBug.Com, Inc.
Getting Things Done
Where tests are run!
During development task assignments
Developers Desktop Unit Testing
During development and integration task assignments

Development Servers Unit and Integration testing
During Integration and system test assignments

Test Lab Servers Integration and System Testing
Acceptance testing
Staging Servers As close as possible to live technologies
Operational system
Live Servers Site monitoring

AmiBug.Com, Inc.
Section 4
Unit Testing Process

AmiBug.Com, Inc.
A Traditional
Design & implement
Approach
Code of assigned task
Design tests, define

Platforms & test cases
Code
Run test cases, identify
defects, regress
Plan Test
Find root cause Trace &
Unit Test Debug critical defects
Implement corrections
Debug
Rework
Document unit testing
Repeatable, Reviewable Follow Up
AmiBug.Com, Inc.
Extreme Programming
• Begin with the end in mind

– Define Test
– Implement Test
– Then “Develop the simplest
code to pass the test”

AmiBug.Com, Inc.
Extreme Programming
“There is a rhythm to developing software unit test first.

You create one test to define some small aspect of the
problem at hand. Then you create the simplest code that
will make that test pass. Then you create a second test.
Now you add to the code you just created to make this
new test pass, but no more! Not until you have yet a
third test. You continue until there is nothing left to test.”
www.extremeprogramming.org

AmiBug.Com, Inc.
An Agile
Organize dev work into
Testable chunks Approach
Build test, code, data,
stubs, drivers, harness
Plan Tests
Create simplest code
to pass tests
Build Test
Run tests
Code
Correct code or test
Unit Test
Rework
Document unit testing
Repeatable, Reviewable Follow Up
AmiBug.Com, Inc.
Getting Started
Practical Tip
1. Understand testing objectives

2. Explicitly list unit tests ideas
3. Review list with peers
4. Prioritize list
5. Develop and test code until all unit test
cases pass or known bugs can be
deferred
AmiBug.Com, Inc.
Unit Testing Ideas

• Collect all testing ideas you can find!
– List
– Sort
– Organize
– Shuffle

AmiBug.Com, Inc.
Testing Ideas
• How to find them?
– Does system do what it is suppose to do?
– Does the system do things it is not supposed to?
– How can the system break?
– How does the system react to it’s environment?
– What characteristics must the system conform to?
– Why have previous or similar projects failed?
– How have previous or similar systems failed?

AmiBug.Com, Inc.
Unit Testing Ideas

• Collect testing ideas
• From testing ideas
build a series of
testing objectives
(TO)
– Each can include all,
part of, or multiple
testing ideas

AmiBug.Com, Inc.
Unit Testing Ideas

• Creative
approaches
– Action verbs
– Mind Maps
– Soap Operas
– Lateral Thinking

AmiBug.Com, Inc.
Unit Testing Ideas

• Investigative
approaches
– We become truffle
snorting pigs and try to
find useful information in
all evidence we discover
– We can even get good
ideas from out of date
sources or unreliable

AmiBug.Com, Inc.
Unit Testing Ideas

• Bug taxonomies
– Collections of possible bugs
– Appendix A of Testing
Computer Software, Kaner,
Falk, Nguyen
– Boris Biezer Taxonomy Otto
Vinter manages
– Shopping cart taxonomy Giri
Vijayaraghavan

AmiBug.Com, Inc.
Unit Testing Ideas

• Requirements
– Use cases
– Functional
requirements
– Quality factors
– Constraints
– Written requirements
– Implicit requirements

AmiBug.Com, Inc.
Unit Testing Ideas

• Usage Scenarios
– Identify classes of
users
– Identify how users
will use system
– Describe scenarios
– Use Story board or
similar approaches
– Identify variations

AmiBug.Com, Inc.
Unit Testing Ideas

• Functionality
Analysis
– Requirements,
Design or Prototypes
can give insights into
– Domain Analysis
– Equivalence classes
– Boundary analysis
– CRUD

AmiBug.Com, Inc.
Unit Testing Ideas

• Failure Modes
– What can break?
– Reaction to invalid input?
– How does software
behave in constrained
environment?
• Memory
• Disk Space
• Network Bandwidth
• CPU capacity
• Shared resources
– Stress, Load, Volume

AmiBug.Com, Inc.
Unit Test Harness

M o d u le C - U n d e r U n it T e s tin g
T e s t H a rn e s s
M o d u le A M o d u le B M o d u le C M o d u le D M o d u le E M o d u le F
T r a n s a c t io n C a p tu re
G e n e ra te d S im u la te d C o m p le te d U n it B e in g C o m p le te d C o m p le te d Test and
S tu b S tu b
fro m T r a n s a c t io n U n it D e v e lo p e d U n it U n it o u tc o m e p ro c e s s
T e s t D a ta te s t r e s u lts
T e s t H a rn e s s
Test Test
C ases R e s u lt s
E la p s e d T im e

AmiBug.Com, Inc.
Interoperability
Maintainability
Dependability
Expandability
Serviceability
Accessibility
Functionality
Adaptability
Re-usability
Auditability
Operability
Availability
Scalability
Testability
Continuity
Portability
Reliability
Usability
Security
Integrity
Application service provider
Automatic content generator
Customized access
Database access
Delivery
Document access
File sharing
Informational
Interactive
Transaction oriented
User-provided content
Workflow oriented
High Focus
Medium Focus Quality Factors Importance For
Low Focus Different Web Application Types
AmiBug.Com, Inc.
Brainstorming
Unit Testing Ideas
• Peer review to identify
and clarify testing ideas
which are
– New
– Missing
– Redundant
– Incorrect
– Incomplete
– Inconsistent
– Vague

AmiBug.Com, Inc.
Unit Testing Ideas

• Test Data Library
– Inspired from reality
– Logs from previous or similar
systems
– Build up SOAP OPERA life
stories
– Build test data catalogues
– Organize so test data can be
useful

AmiBug.Com, Inc.
Unit Testing Ideas

• Oracle Collection
– Strategies to assess
correctness
– Similar systems
– Old systems
– Subject matter
experts
– Gurus
– Standards

AmiBug.Com, Inc.
Unit Testing Tools

• Tools
– Dynamic analysis
– Static analysis
– Test case generation
– Test engines
– Home brew with
correct skills
– Danny Faught Open
Testware ideas

AmiBug.Com, Inc.
Which Unit Test?

•Impact estimation
–For each unit test idea guesstimate:
• benefit of implementation
• consequence of implementation
• benefit for not implementing
• consequence of not implementing
–How credible are values?

AmiBug.Com, Inc.
How to Decide?
Understanding Complex Technology Quantitatively By Tom Gilb
Rank Credibility
0.0 Wild guess, no credibility
0.1 We know it has been done somewhere
0.2 We have one measurement somewhere
0.3 There are several measurements in the estimated range
0.4 The measurements are relevant to our case
0.5 The method of measurement is considered reliable
0.6 We have used the method in-house
0.7 We have reliable measurements in-house
0.8 Reliable in-house measurements correlate to independent external
measurements
0.9 We have used the idea on this project and measured it
1.0 Perfect credibility, we have rock solid, contract- guaranteed, long-term, credible
experience with this idea on this project and, the results are unlikely to
disappear

AmiBug.Com, Inc.
Which Unit Test?

Test Idea Rejection – What If?
–If the cost/benefit does not make
business sense then consider
implementing:
• part of the test, could that lead to part of the
benefit at a more reasonable cost?
• more than the stated test, would that generate
more benefit?
• a different test than the stated idea, could that
generate more benefit for less cost?

AmiBug.Com, Inc.
Deciding what not to

test?
• Time pressure
– Should we skip a test?
– If test failed could system still be of
value to some stakeholder?
– If test was skipped could important
bugs have been otherwise found?

AmiBug.Com, Inc.
Sources of
Information
• Version control system
– Monitor changes
– Track where work is
– Track where stability is
• Encourage finding defects earlier than system
testing
– Inspections of code, design, requirements
– Unit Testing
– Informal code check in peer reviews
AmiBug.Com, Inc.
Testability
• Can application be controlled
by non-gui api for all business
functions?
• Can application logging be
controlled and logs viewed by
testing?
• Can everything which can be
set or changed be queried
programmatically?
• Is there a static equivalent for
dynamic guis?

AmiBug.Com, Inc.
Section 5
Unit Testing Cost Benefit

AmiBug.Com, Inc.
Unit Testing Cost and Benefit
Unit Testing Effort

• Types of work in any development task
assignment
– Analysis
– Design
– Implementation
– Unit Testing
– Rework
– Documentation related to assigned work
– Configuration Management
– Administration
AmiBug.Com, Inc.
Unit Testing Effort

• Individual development tasks are often
5 to 10 person days effort
– Shorter projects leads to shorter tasks
• Involves many objects, modules,
configurations are touched to implement
requirement
• Multidisciplinary approach - polyvalent
• Multiple technical skills - wiz kid
AmiBug.Com, Inc.
Example Effort
Breakdown
Task Breakdown Description Days Percent
Analysis Understand problem 0.5 5%
Design Map out solution 2.0 20%
Implementation Implement solution 3.0 30%
Unit Testing Confirm solution solves 3.0 30%

problem
Rework Correct defects and other 1.0 10%
errors or omissions
Documentation Update project technical 0.5 5%
documentation, describe
work done
AmiBug.Com, Inc.
Example Effort
Breakdown - SQUEEZED
Task Breakdown Description Days Percent
Analysis Understand problem 0.5 8%
Design Map out solution 1.0 15%
Implementation Implement solution 3.0 46%
Unit Testing Confirm solution solves 1.0 15%

problem
Rework Correct defects and other 0.5 8%
errors or omissions
Documentation Update project technical 0.5 8%
documentation, describe
work done
AmiBug.Com, Inc.
Economics
• Cost of fixing a defect sooner (closer to
when defect was injected) is
significantly less than fixing the defect
later
• Generally
– Find and fix problems as early as
practically possible

AmiBug.Com, Inc.
Relative Cost to Repair

Rational

AmiBug.Com, Inc.

Rational

AmiBug.Com, Inc.
Example
Rework Effort
System Testing Phase - Rework Effort
1000.00
900.00
800.00
700.00
600.00 To Go Effort Estimate

Total Testing Effort Done
500.00
Total Project Testing Effort
400.00 Total Rework Effort Done
300.00
200.00
100.00
0.00
24-Sep 1-Oct 7-Oct 14-Oct 21-Oct 28-Oct 4-Nov 11-Nov 18-Nov 25-Nov 2-Dec 10-Dec 17-Dec 21-Dec

AmiBug.Com, Inc.

Boehm
Phase Relative cost to repair

Requirement 1
Design 3-6
Code 10
Unit Test 15-40
Integration Test 30-70
Field 40-1000
AmiBug.Com, Inc.
Cost of Java Bug Removal
Mitchell
Phase Cost
Definition $1.00
High Level Design $2.00
Low Level Design $5.00
Code $10.00
Unit Testing $15.00
Integration Testing $22.00
System Testing $50.00
Post-Delivery $100.00 and more
AmiBug.Com, Inc.
Figures from Xerox
Activity Minutes to fix

Code Review 3
Code Inspections 25
Module Testing 25
System Testing 1400
… even the most experienced software engineer
injects about one defect for ten lines of code …
Watts S. Humphrey – Why Quality Pays?
AmiBug.Com, Inc.
What we can expect?

Phase Benefit
Development •Improved estimates
•Fewer defects injected
System Testing •Fewer test cycles (Faster)
•Focus on important system bugs
Maintenance •Fewer field reported bugs
•Improved quality for end user
Overall •Shorter development cycle
•More revenue – time to market!
AmiBug.Com, Inc.
Unit Testing Approaches

AmiBug.Com, Inc.
Black Box Testing

• Tester views the program
as a black box
• Test is not concerned
about the internal
behavior and structure of
the program
• Test is designed to
observe and confirm
outcome of program in
response to input and
system state
AmiBug.Com, Inc.
White Box Testing

• Tester reviews the
programs behavior,
internal structure and data
flow
• Test design is based on
examination of code
• Used by developers as
code is written
• Assumes code required
• Does not confirm
requirements are met
AmiBug.Com, Inc.
Static Testing
• Testing source code of
software
– Reviews
– Walkthroughs
– Inspections
– Static analysis (automatic or
manual)
– Study code and development
artifacts in order to gauge
correctness and identify defects

AmiBug.Com, Inc.
Basis Path Testing

• Method introduced by
McCabe
– Create a flow graph
– Identify all unique executable
paths through the code being
tested (called the Basis Set)
– Derive one test case for each
path in the Basis Set
– White Box method

AmiBug.Com, Inc.
Unit Test Case

Design
• Unit Test Case Characteristics

– Consider Input
– Consider Outcome
Input/Outcome
– Consider Initial State
– Consider End State
Input/Outcome

AmiBug.Com, Inc.
State Modeling
• Unit Test Case Design
– All state transitions
– All paths through the system
– Rational input
– Unexpected input
– Can we get to all states?

AmiBug.Com, Inc.
Unit Test Case Design
• Equivalence Classes
– Sets of input events which are similar and exercise the
application in the same way!
• Boundary Values
– Sets of input events on or very close to the boundary of
accepted valid input
• Test cases should include a mix of valid and
invalid input for all equivalence classes and
boundary conditions
AmiBug.Com, Inc.
Test Case Design
• Input
– Invalid inputs
• at least one test with each possible type of invalid input
for each type of field on a dialogue
• use gray box methods to determine common types of
fields
– Pairs
• at least one test for each possible pair of invalid inputs

AmiBug.Com, Inc.
Test Case Design
• Error Conditions
– Error conditions
• at least one test for each possible error
condition
• pairs of error conditions

AmiBug.Com, Inc.
API Test Cases

• API - libraries - embedded components
– special considerations
• have test beds written in several different
languages and bindings [ test cases
independent ]
• treat as platform swap
• black box
• data driven
• use language independent MACROS to
generate CALL SEQUENCES!
AmiBug.Com, Inc.
API Test Cases

• API - libraries - embedded components
– special considerations
• start with valid calls in rational order
• sane
• use state transition diagrams to derive test
cases
• call functions with invalid parameters in correct
state
• call functions with valid parameters in wrong
state
AmiBug.Com, Inc.
Wisdom
• Repeated testing
– Make sure test cases can be repeated
• allows for regression
• allows for data driven test automation
– Test descriptions should be explicit

AmiBug.Com, Inc.
Section 6
Coverage

AmiBug.Com, Inc.
Coverage
Test Coverage
• Coverage is some measure of how

much of the code under test is being
exercised when tests are executed.
– Are we trying each function?
– Are we trying each line of code?
– Are we not executing some code when we
test the application? Should we?
AmiBug.Com, Inc.
Coverage
Coverage
• Line Coverage
• Branch Coverage
• Condition Coverage
• Coverage tools

AmiBug.Com, Inc.
Coverage
Line Coverage
• Each line of code must be executed

once during testing.
• Weakness is that even if each line is
executed during testing there are many
possible states for each variable and
condition

AmiBug.Com, Inc.
Coverage
Branch Coverage
• All lines of code are tested

• All branches in code are covered

AmiBug.Com, Inc.
Coverage
Basis Path Coverage
• All conditions of all branches are

covered
• Conditions to get branch to go one way
or another

AmiBug.Com, Inc.
Coverage
Coverage Example
1 If (condition A)
• Sample code 2 { code A }
3 If (condition B)
4 { code B }
5 If (condition C)
6 { code C }
Full line or branch coverage if A, B, C true
Full condition coverage if A, B, C true and false
Full path coverage if all combinations of A, B, C true or false

AmiBug.Com, Inc.
Coverage
Coverage Exercise
• Code sample
• Define test cases which will give full line
coverage

AmiBug.Com, Inc.
Coverage
Coverage Exercise
begin
//
// check range - value must be between 1 and 99
//
if ( ( SideA < 1 ) or ( SideA > 99 ) ) then
begin
Msg := 'A out of Range' ;
end
else
begin
if ( ( SideB < 1 ) or ( SideB > 99 ) ) then
begin
Msg := 'B out of Range' ;
end
else
begin
if ( ( SideC < 1 ) or ( SideC > 99 ) ) then
begin
Msg := 'C out of Range' ;
end
end
end
end ;
/
AmiBug.Com, Inc.
Coverage
Coverage Exercise
begin
//
// check range - value must be between 1 and 99
//
if ( ( SideA < 1 ) or ( SideA > 99 ) ) then A = -100, B=10, C=10
begin
Msg := 'A out of Range' ; A=10,B=-100,C=10
end A=10,B=10,C=-100
else
begin
if ( ( SideB < 1 ) or ( SideB > 99 ) ) then
begin
Msg := 'B out of Range' ;
end
else
begin
if ( ( SideC < 1 ) or ( SideC > 99 ) ) then
begin
Msg := 'C out of Range' ;
end
end
end
end ;
/
AmiBug.Com, Inc.
Coverage
Coverage Tools
• Execution coverage monitors

– often require a special build of the program to link
in special coverage analysis software or hooks
– great for from time to time seeing how much of
code is exercised by testing activities
– generally to heavy to use for each test cycle

AmiBug.Com, Inc.
Coverage
Coverage Tools
• Execution coverage monitors

– because it often forces a special build the
code being tested is not the same binary
as a commercial cut
• watch out for performance, load and system
resource limit side effects
– tool is useful to measure performance of
test plan - not performance of application!
AmiBug.Com, Inc.
Go With the Flow!
Coverage
START
Result = 0
Read
A, B, C
Do A Stuff
A True? Yes Result =
Result +4
Do B Stuff
No B True? Yes Result =
Result +2
Do C Stuff
No C True? Yes Result =
Result +1
No Print
Result

STOP AmiBug.Com, Inc.
Go With the Flow!
Coverage
START
Truth Table
A B C Result
Result = 0 False False False 0
False False True 1
False True False 2
False True True 3
True False False 4
True False True 5
True True False 6
Read True True True 7
A, B, C
Do A Stuff
Result +4
Do B Stuff
Result +2
Do C Stuff
Result +1
No Print
Result

Go With the Flow!
Coverage
START
Test Cases to achieve

100% LINE COVERAGE
Result = 0 1
A B C Result
True True True 7
Read
2
A, B, C
Do A Stuff
3 A True? Yes Result = 4
Result +4
Do B Stuff
No B True? Yes Result = 6
Result +2
5
Do C Stuff
No C True? Yes Result = 8
Result +1
No Print
9
Result

STOP 10 AmiBug.Com, Inc.
Go With the Flow!
Coverage
START

100% BRANCH COVERAGE
Result = 0
A B C Result
Falsie False False 0
True True True 7
Read
A, B, C
Do A Stuff
Result +4
Do B Stuff
Result +2
Do C Stuff
Result +1
No Print
Result

Go With the Flow!
Coverage
START

100% PATH COVERAGE
A B C Result Path
Result = 0 1
False False False 0 1,2,3,5,7,9,10
False False True 1 1,2,3,5,7,8,9,10
False True False 2 1,2,3,5,6,7,9,10
False True True 3 1,2,3,5,6,7,8,9,10
True False False 4 1,2,3,4,5,7,9,10
Read
True False True 5 1,2,3,4,5,7,8,9,10
2 True True False 6 1,2,3,4,5,6,7,9,10
A, B, C
True True True 7 1,2,3,4,5,6,7,8,9,10
Do A Stuff
3 A True? Yes Result = 4
Result +4
Do B Stuff
No B True? Yes Result = 6
Result +2
5
Do C Stuff
No C True? Yes Result = 8
Result +1
No Print
9
Result

STOP 10 AmiBug.Com, Inc.
Coverage
Useful coverage
information
• Has every function been used at least

once during the test pass?
• What % of lines of code of each module
are executed during testing?
• If there is a lot of code not being run -
do we really need it?
AmiBug.Com, Inc.
Coverage
About Coverage Tools
• Effort to get coverage analysis running

is significant and should be done from
day 1
• Today a lot of code is put together by
cut and paste reuse strategy
– not all code is needed
– it is too risky to remove unneeded code
AmiBug.Com, Inc.
Section 7
Organization

AmiBug.Com, Inc.
Unit Testing Organization
Top Down Testing
• White box method

starting with main
program and
working down
through the
software.
• Stubs must be
created for units not
yet completed.
AmiBug.Com, Inc.
Bottom Up Testing
• White box method
starting with lower
level units.
• Driver units must be
created for units not
yet completed, each
time a new higher
level unit is added to
those already tested.
AmiBug.Com, Inc.
Sandwich Testing
• Combining Bottom
Up and Top Down
approaches.
• Blend of stubs and
drivers depending
on part of software
being exercised.

AmiBug.Com, Inc.
Platform /
Configuration
• Ensure functionality
operates as required on
Testing
different hardware and
software configurations
• Different versions of
operating systems
• Different locales
• Different versions of www
browsers, plug-ins
• Different versions of any
co-dependent software
AmiBug.Com, Inc.
Assertion Testing
• “Asserts”
– Added as in-line code
– Ensure that software is
operating in the correct
state with correct values
of certain variables,
tables, parameters or
other data
– Assertions often
implemented as
MACROS
– Generally disabled in
commercial builds

AmiBug.Com, Inc.
Assertion Testing
• Cautionary Warning About Assertions

– excellent practice for developers to ensure
code works
– can cause false failures if not implemented
carefully (don’t care condition handling)
– ensure all developers use “Asserts”
consistently!
AmiBug.Com, Inc.
Section 8
Paradoxes Problems and Politics

AmiBug.Com, Inc.
Paradoxes, Problems and Politics
Do we still need
independent testing?
• Number of defects introduced at
development and early phases and
discovered at system testing will drop!
• We will focus system testing staff on
issues related to how the application
operates as a system and how it
interacts with different software,
systems and in different environments.
AmiBug.Com, Inc.
Do we need a Unit
Testing Bug Database?
• No – unit testing bug databases are

optional and often discouraged – if used
they should be independent of system
test bug list.
• Bugs known, but not fixed, (on purpose)
at unit test stage should be entered in
the system test database
AmiBug.Com, Inc.
What about using
automated test case
generators?
• These tools are risky since they create
their test cases exclusively based on
the code as written. If code is wrong –
test case will confirm code is wrong!
• Used with caution they can help identify
important problems and enforce
disciplined development habits!
AmiBug.Com, Inc.
Should we develop our

own test harness?
• When developing API based systems it is advisable to

develop a test harness which can be shared with
system testing team
• Any code written to run unit tests should be
maintained in source control systems.
• Third Party test harnesses, such as J-Unit, are
available free of charge and may provide a simple
example environment
• It is a software project and needs requirements,
configuration management, testing and a full lifecycle.
AmiBug.Com, Inc.
How do we know that
Unit Testing is
effective?
• Measures of interest
– Amount of effort correcting bugs found
during system test
• Should reduce by a margin larger than added
development cost of doing unit testing

AmiBug.Com, Inc.
Should we try
increasing unit testing
on all projects?
• Probably a good idea to instill the concept by
introducing it to one pilot team
• Try to keep all teams within one step of
process maturity
• Build on success
• Learn from mistakes
• Every organization has a different
temperament
AmiBug.Com, Inc.
Does Unit testing impact
the relationship between
developers and testers?
• Yes indeed! Lots of evidence.
• Better quality leads to better focus and
communications.
• Focus of system testing is on bugs
which could not reasonably or
economically have been discovered
during development!
AmiBug.Com, Inc.
How do developers react to

unit testing?
• Software development professionals want to

deliver quality code that works and meets and
important business need.
• As long as unit testing effort is included in
development estimation and commitments.
… begin with the end in mind …

AmiBug.Com, Inc.
Finished?
• How do you know you are finished?

AmiBug.Com, Inc.
You know you are
finished when
…
• … all high priority unit test ideas, unit
tests case have passed ...

AmiBug.Com, Inc.
You know you are
finished when
…
• … and the only bugs left are the ones
that you can live with …
At least for now!

AmiBug.Com, Inc.
Thank You
• Questions?

AmiBug.Com, Inc.
Appendix A
Example Test Harness

AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
• Homebrew unit test harness which executes a
library of test cases
• VC++ Code for MS-Windows security client
(firewall, anti-virus, pop-up blocker, parental
control) with Linux server back end
• Hourly builds with full unit test regression
– Complete build from top of source tree
– Complete run of all test cases
– Report results
– Updates status
AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
• Workflow
– Development lead assigns activity to developer
traced with issue tracking system based on
BugZilla
– Developers check out modules from CVS
• Modify or Create code
• Modify or Create unit test modules
– Unit Testing Modules
• Basic or smoke test
• Intermediate testing
• Exhaustive or comprehensive test

AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
• Samples

AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
• Samples

AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
• Samples

AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
• Samples

AmiBug.Com, Inc.
Test Harness
Example Unit Test

Harness
Status: Now looping over commands...
Exec: CliAgentD run interactionTest clientbase/zkbaseuitest
Output:
[0.20 second(s)] Test clientbase/zkbaseuitest succeed - (5/5)
Exec: CliAgentD runall test
Output:
[18.15 second(s)] Test BusinessLogic/UpgradeMgr succeed - (12/12)
[3.205 second(s)] Test PacketShim/PacketDispatcher succeed - (11/11)
xxx
[0.111 second(s)] Test wordscan/WSDictionaryUnitTest succeed - (13/13)
[0.30 second(s)] Test wordscan/WSPreferencesUnitTest succeed - (58/58)
[14.400 second(s)] Test wordscan/WSScannerUnitTest succeed - (8929/8929)
xxx
[0.200 second(s)] Test zktools/FirewallRuleManagerUnitTest succeed - (293/293)
[0.30 second(s)] Test zktools/FirewallUnitTest succeed - (200/200)
xxx
[0.0 second(s)] Test zkui/commom/UiNavEntry succeed - (0/0)
Summary of QWERTY Unit Tests:

Tests failed : 0
Tests succeed : 12805
-------------------------
Tests executed : 12805
-------------------------
Success Rate : 100%

AmiBug.Com, Inc.
Appendix B
Equivalence

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
– Defined
– Purpose
– Governance
– Assumptions
– Fallacies
– RobSab Rules of Thumb
– Budget Oriented
– Multiple Variables
– Examples

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• Defined
– An equivalence class is a subset of all possible input values to a field of the software being
tested
– Each member of an equivalence class is assumed to be processed the same way by the
software being tested.
» Assumption made by tester designing or selecting test date
» Assumption may be made based on knowledge of the code
» Assumption need not be true
– Each input field of the software being tested may have many different equivalence classes
– Each equivalence class of an input field of the software being tested is not mutually exclusive

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• Purpose
– We define equivalence classes for each input field to an application to help
us focus our testing and to help reduce the number of test cases required.
– If we have decided to invest more testing a particular field then we will model
more equivalence classes for the field
– A minimum of two equivalence classes are recommended for each input field
» Class of valid input
» Class of invalid input

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• Governance
– Requirements
» Business logic
» Capabilities
» Ranges
» Constraints
– Code
» Decisions
» Intermediate computations
– Data
» Input fields
» Database
» Internal structures

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• Assumptions
– We assume the class exists
– We assume all elements of the class are processed the same
– We assume the class is the best or better class to test
– We assume that defining equivalence classes is a worthwhile
investment, perhaps we could be doing something better with our time
– We assume past experience in equivalence class based testing may
be relevant for the current or future testing projects

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
– Fallacies
» Equivalence classes exist
– Fact
» At Best an Equivalence class is a MODEL

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• RobSab Rules of Thumb
– For each equivalence class choose three member values randomly

for testing the input field
– Name each equivalence class!
– Reuse equivalence classes.

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• Budget Oriented
– Choose more classes for fields you decide to test more

rigorously
– Choose less classes for fields you decide to test lightly

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
• Multiple Variables
– Define equivalence classes for each variable
– Mix and match equivalence classes across variables
– Use Random approaches for independent variables

» For example uniform random distribution of all possible classes for all fields
– Use Combinatory approaches for dependent variables

» For example All Pairs approach

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Square Root function in Windows Calculator
» Valid Range Real
» Invalid Range Real
» Valid Range Integer
» Invalid Range Integer
» Single Byte Integer
» Double Byte Integer
» Four Byte Integer
» Exponent
» Valid Precision
» Invalid Precision
» Too many digits
» Way too many digits

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Login Name
» Valid Authorized Name
» Valid Unauthorized Name
» Invalid Name
» Mixed Latin Accented Name
» Mixed CJK Name
» Mixed Cyrillic Latin Name
» Mixed Greek Latin Name
» Mixed Latin-2 Latin Name
» Mixed Arabic Latin Name
» Mixed Hebrew Latin Name
» Valid characters too short name
» Valid characters too long name

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Login Name
» Valid characters WAY TOO LONG name
» Leading spaces valid name
» Leading tabs valid name
» Mixed edit symbols valid characters
» Mixed numbers valid characters
» Mixed accented characters valid characters
» ALL CAPS valid name
» ALL Lower Case valid name
» Mixed control characters valid characters
» Mixed alt graphics characters valid characters
» Leading control characters
» Trailing control characters

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Login Name
» HTML Fragments
» Web Pages
» Document Files
» Binary Large Objects (BLOBS)
» JavaScript Fragments
» VB Script Fragments
» SQA Fragments
» Quoted strings
» XML Strings
» PDF Files
» Captured HTTP submits

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Login Name
» Longest possible valid authorized name with appended strings
» Longest possible valid authorized name with prefixed strings
» Special control characters intermixed
» Multiple lines with CR delimiters
» Multiple lines with CR LF delimiters
» Multiple lines with LF CR delimiters
» Multiple lines with LF delimiters
» Names with HL7 message wrappers
» Names wrapped with Braces

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Login Name
» What about Invalid but Authorized names?
» Can we load names directly in authentication database
without going through an API or a GUI or both?

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Phone Number
» Valid and active phone number
» Valid and inactive phone number
» Invalid phone number
» Local
» Long distance
» Toll Free
» Extension
» Dial out prefix
» Overseas prefix
» Six digit phone number
» Seven digit phone number
» Ten digit phone number

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Phone Number
» Time delay pauses
» Format with brackets
» Leading spaces valid number
» Trailing spaces valid number
» Dashes in format
» Brackets in format
» Out of sequence brackets
» Not closed brackets
» Nested brackets
» Out of sequence dashes
» Leading brackets
» Leading dashes

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– Phone Number
» Missing dashes
» Missing brackets
» Group of four digits split with spaces
» Spaces instead of dashes
» Spaces instead of brackets

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– File Path
» Missing directory
» Existing directory
» Missing file
» Existing file
» Path with spaces
» Path without spaces
» Filename with spaces
» Filename with out spaces
» Valid file name
» File name with accented characters
» Path name with accented characters
» File name without extension

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– File Path
» Valid dos filename
» Filename longer than dos limits
» Filename with mixed upper and lower case
» Pathname with mixed upper and lower case
» Visible directory
» Invisible directory
» Access restricted directory
» Access restricted file

AmiBug.Com, Inc.
Equivalence
Equivalence Classes
Example
– File Path
» What about file system
» What about mounted file systems from foreign sources

AmiBug.Com, Inc.
Appendix C
Combinations

AmiBug.Com, Inc.
Combinations
All Pairs Testing

– Parameters and Variation
– All Parameter Testing
– Exhaustive All Combination Testing
– Statistics about Combinations
– Pairs
– Tools
– Triples
– Random Variation
– Blending All Pairs and Random Variation

AmiBug.Com, Inc.
Combinations
All Pairs Testing

– Parameters and Variation
» During test case design is it often wise to parameterize
any data entered or decisions made for any testing
objective or usage scenario
» Test cases can be defined as containing a
predetermined list of test data or decisions
» Confidence increases as more test cases are used with
varied test data or decisions

AmiBug.Com, Inc.
Combinations
All Pairs Testing
• All Parameter Testing

– Exhaustive
» For each parameter define equivalence classes
» At least one test case for each combination
» Total combinations is determined by multiplying all
combinations

AmiBug.Com, Inc.
Combinations
All Pairs Testing
– Statistics about Combinations

» Vary parameters in a manner statistically
equivalent to expected distribution in “real world”
• How many test cases?

• Confidence level?
• Confidence interval
• Sample size calculator

AmiBug.Com, Inc.
Combinations
All Pairs Testing
• Pairs
– Orthogonal array analysis (OATS)
– At least one test cases for each pairing of variables
– Open Source Tool
» allpairs
» www.satisfice.com
» James Bach

AmiBug.Com, Inc.
All Pairs
PAIRING DETAILS
var1 var2 value1 value2 appearances cases
OpSys Browser WinXP IE 1 1
OpSys Browser WinXP Netscape 1 2
OpSys Browser WinXP Opera 1 7
OpSys Browser Win2k IE 2 3, 10
Testing
OpSys Browser Win2k Netscape 1 4
OpSys Browser Win2k Opera 1 8
OpSys Browser WinME IE 1 5
OpSys Browser WinME Netscape 2 6, 11
OpSys Browser WinME Opera 1 9
OpSys Server WinXP Apache 1 1
OpSys Server WinXP IIS 1 2
OpSys Server WinXP Coldfusion 1 7
OpSys Server Win2k Apache 2 4, 8
OpSys Server Win2k IIS 1 3
OpSys Server Win2k Coldfusion 1 10
OpSys Browser Server Acrobat OpSys Server WinME Apache 1 11
WinXP IE Apache Installed OpSys Server WinME IIS 1 9
Win2k Netscape IIS Not Installed OpSys Server WinME Coldfusion 2 5, 6
OpSys Acrobat WinXP Installed 2 1, 7
WinME Opera Coldfusion OpSys Acrobat WinXP Not Installed 1 2
OpSys Acrobat Win2k Installed 1 3
OpSys Acrobat Win2k Not Installed 3 4, 8, 10
OpSys Acrobat WinME Installed 3 6, 9, 11
OpSys Acrobat WinME Not Installed 1 5
Browser Server IE Apache 1 1
TEST CASES Browser Server IE IIS 1 3
case OpSys Browser Server Acrobat pairings Browser Server IE Coldfusion 2 5, 10
Browser Server Netscape Apache 2 4, 11
1 WinXP IE Apache Installed 6
Browser Server Netscape IIS 1 2
2 WinXP Netscape IIS Not Installed 6 Browser Server Netscape Coldfusion 1 6
3 Win2k IE IIS Installed 5 Browser Server Opera Apache 1 8
4 Win2k Netscape Apache Not Installed 5 Browser Server Opera IIS 1 9
Browser Server Opera Coldfusion 1 7
5 WinME IE Coldfusion Not Installed 6
Browser Acrobat IE Installed 2 1, 3
6 WinME Netscape Coldfusion Installed 5 Browser Acrobat IE Not Installed 2 5, 10
7 WinXP Opera Coldfusion Installed 4 Browser Acrobat Netscape Installed 2 6, 11
8 Win2k Opera Apache Not Installed 3 Browser Acrobat Netscape Not Installed 2 2, 4
Browser Acrobat Opera Installed 2 7, 9
9 WinME Opera IIS ~Installed 3
Browser Acrobat Opera Not Installed 1 8
10 Win2k ~IE Coldfusion ~Not Installed 1 Server Acrobat Apache Installed 2 1, 11
11 WinME ~Netscape Apache ~Installed 1 Server Acrobat Apache Not Installed 2 4, 8
Server Acrobat IIS Installed 2 3, 9
Server Acrobat IIS Not Installed 1 2
Server Acrobat Coldfusion Installed 2 6, 7
Server Acrobat Coldfusion Not Installed 2 5, 10

AmiBug.Com, Inc.
Combinations
All Pairs Testing
Service Level Position State When Sorted Type Origin Destination

Next Day None Last Day Bag Local Local
2nd Day Stack Last Night Can International International
3rd Day Empty Container Previous Day Trailer
Ground Part Full Container
Previous Night Belly
Insured Closed ContainerEarlier
Live
6 5 5 4 2 2
combinations 2400

AmiBug.Com, Inc.
TEST CASES
case Service Level Position State When Sorted Type Origin Destination pairings
1 Next Day None Last Day Bag Local Local 15
2 Next Day Stack Last Night Can International International 15
3 2nd Day None Last Night Trailer Local International 13
4 2nd Day Stack Last Day Belly International Local 13
5 3rd Day Empty Container Previous Day Bag International International 14
6 3rd Day Part Full Container
Previous Night Can Local Local 14
7 Ground Empty Container Previous Night Trailer International Local 12
8 Ground Part Full Container
Previous Day Belly Local International 12
9 Insured Closed ContainerEarlier Bag Local Local 12
10 Insured None Previous Day Can International Local 9
11 Live Closed ContainerLast Day Can International International 11
12 Live Stack Earlier Trailer Local International 9
13 Insured Empty Container Last Night Belly Local Local 8
14 Insured Part Full Container
Last Day Trailer International International 8
15 Live None Previous Night Belly ~International International 7
16 Live Empty Container Earlier Can International Local 6
17 Next Day Part Full Container
Earlier Belly ~International ~Local 5
18 Next Day Closed ContainerPrevious Day Trailer ~Local ~Local 6
19 2nd Day Closed ContainerPrevious Night Bag ~International ~International 5
20 2nd Day Part Full Container
Last Night Bag ~Local ~Local 4
21 3rd Day Stack Last Day Bag ~Local ~Local 3
22 3rd Day Closed ContainerLast Night Belly ~International ~International 5
23 Ground None Earlier Can ~Local ~International 4
24 Ground Stack Previous Night Bag ~International ~Local 3
25 Live Empty Container Last Day Bag ~Local ~International 2
26 2nd Day Stack Previous Day Can ~Local ~International 3
27 3rd Day None Earlier Trailer ~International ~Local 3
28 Next Day Empty Container Previous Night ~Belly ~Local ~International 2
29 Insured Stack Previous Night ~Trailer ~Local ~International 2
30 Live Part Full Container
Last Night ~Bag ~International ~Local 2
31 2nd Day Empty Container Earlier ~Can ~International ~International 2
32 Ground Closed ContainerLast Day ~Can ~Local ~Local 2
33 Ground ~Part Full Container
Last Night ~Trailer ~International ~International 1
34 Live ~None Previous Day ~Belly ~Local ~Local 1

AmiBug.Com, Inc.

Sabourin 507 - 607 Unit Testing

Uploaded by

Copyright:

Available Formats

You might also like

Sabourin 507 - 607 Unit Testing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sabourin 507 - 607 Unit Testing

Uploaded by

Copyright:

Available Formats

Unit Testing Workshop

Overview and Some Philosophy

June 21, 2021 © Robert Sabourin, 2005 Slide 2

June 21, 2021 © Robert Sabourin, 2005 Slide 3

“The main objective is to make sure

June 21, 2021 © Robert Sabourin, 2005 Slide 4

June 21, 2021 © Robert Sabourin, 2005 Slide 5

June 21, 2021 © Robert Sabourin, 2005 Slide 6

June 21, 2021 © Robert Sabourin, 2005 Slide 7

• Plan, Do Check, and Act:

June 21, 2021 © Robert Sabourin, 2005 Slide 8

June 21, 2021 © Robert Sabourin, 2005 Slide 9

June 21, 2021 © Robert Sabourin, 2005 Slide 10

June 21, 2021 © Robert Sabourin, 2005 Slide 11

June 21, 2021 © Robert Sabourin, 2005 Slide 12

June 21, 2021 © Robert Sabourin, 2005 Slide 13

June 21, 2021 © Robert Sabourin, 2005 Slide 14

"No! Try not, Do. Or do not.

June 21, 2021 © Robert Sabourin, 2005 Slide 15

“…begin with the end in mind …

June 21, 2021 © Robert Sabourin, 2005 Slide 16

June 21, 2021 © Robert Sabourin, 2005 Slide 17

June 21, 2021 © Robert Sabourin, 2005 Slide 18

June 21, 2021 © Robert Sabourin, 2005 Slide 20

Unit Testing in Development

June 21, 2021 © Robert Sabourin, 2005 Slide 22

Purpose of Unit Testing

June 21, 2021 © Robert Sabourin, 2005 Slide 23

Testing can take place as part

core workflow involved in development

– Types of development processes

June 21, 2021 © Robert Sabourin, 2005 Slide 27

June 21, 2021 © Robert Sabourin, 2005 Slide 28

June 21, 2021 © Robert Sabourin, 2005 Slide 29

June 21, 2021 © Robert Sabourin, 2005 Slide 30

June 21, 2021 © Robert Sabourin, 2005 Slide 31

June 21, 2021 © Robert Sabourin, 2005 Slide 32

P re lim ina ry ite r. ite r. ite r. iter. iter. iter. iter.

June 21, 2021 © Robert Sabourin, 2005 Slide 33

June 21, 2021 © Robert Sabourin, 2005 Slide 34

Traditionally done by developers when modules/units of code are developed.

The entire system has been integrated together.

Bugs are not Good or Bad

June 21, 2021 © Robert Sabourin, 2005 Slide 36

Some bugs are important

June 21, 2021 © Robert Sabourin, 2005 Slide 37

Some bugs are dangerous

June 21, 2021 © Robert Sabourin, 2005 Slide 38

• Setting the priority and severity of a bug

June 21, 2021 © Robert Sabourin, 2005 Slide 39

Not Urgent Not Urgent

June 21, 2021 © Robert Sabourin, 2005 Slide 40

We have precious little time to run tests!

We must always be prepared!

June 21, 2021 © Robert Sabourin, 2005 Slide 41

Getting - Where can I find them?

- Who manages them? - Are builds delivered?

During development and integration task assignments