Integration testing

• Objective: ensure assembled modules, that work

fine in isolation, work together
– Attempt to find interface faults

• Need a module call graph.

main

A B C

D E F
 Integration Strategy

• How low-level modules are assembled to form

higher-level program entities

• Strategy impacts on
– the form in which units test-cases are written
– the type of test tools to use
– the order of coding/testing units
– the cost of generating test cases
– the cost of locating and correcting detected
defects
 Integration testing strategies

• Several different strategies can be used for integration

testing.
• Comparison criteria:
– fault localization
– effort needed (for stubs and drivers)
– degree of testing of modules achieved
– possibility for parallel development
• Examples of strategies
– Big-bang
– Top-down
– Bottom-up
– Sandwich
 Big Bang Integration

• Non-incremental strategy
– Unit test each module in isolation
– Integrate as a whole
main test
main
A B C test
A
test
D E F B test
test main, A, B, C
C D, E, F
test
D
test
E
test
F
 Big Bang Integration

• Advantages
– Convenient for small systems

• Disadvantages
– Need driver and stubs for each module
– Integration testing can only begin when all
modules are ready
– Fault localization difficult
– Easy to miss interface faults
 Top-down Integration

• Incremental strategy
1. Start by including highest level
modules in test set. test
main
– All other modules replaced by
stubs or mock objects.
2. Integrate (i.e. replace stub by real
module) modules called by called by test
modules in test set. main, A,
B,C
3. Repeat until all modules in test set.

main
test
main, A, B, C
D, E, F
A B C

D E F
 Top-down Integration

• The integration order can be modified

to: test
main
– include critical modules first
– leave modules not ready to later
test
main main, A, C

A B C
test
main, A,
C, D, E, F
D E F

test
main, A, B, C
D, E, F
 Top-down Integration

• Advantages
– Fault localization easier
– Few or no drivers needed
– Possibility to obtain an early prototype
– Different order of testing/implementation possible
– Major design flaws found first
– in logic modules on top of the hierarchy
• Disadvantages
– Need lot of stubs / mock objects
– Potentially reusable modules (in bottom of the hierarchy)
can be inadequately tested
 Bottom-up Integration

• Incremental strategy
– Test low-level modules, then
– Modules calling them until highest level module
test
main D test
D,E,A
A B C
test test
test
E main, A, B,
B
D E F
C
D, E, F
test test
F C,F
 Bottom-up Integration

• Advantages
– Fault localization easier (than big-bang)
– No need for stubs / fewer mock objects
– Logic modules tested thoroughly
– Testing can be in parallel with implementation

• Dis-advantages
– Need drivers
– High-level modules (that relate to the solution logic)
tested in the last (and least)
– No concept of early skeletal system
 Sandwich Integration
• Combines top-down and bottom-up approaches
• Distinguish 3 layers
– logic (top) - tested top-down
– middle
– operational (bottom) – tested bottom-up
test
main D test
D,E,A
A B C
test test
E main, A, B,
D E F
C
test test D, E, F
F C,F

test
main test
main, A, B, C
 Modified Sandwich Integration

• Combines top-down and bottom-up approaches

• Modules tested first in isolation before

integration test
A
test
main D test
D,E,A
A B C
test test test
E C main, A, B,
D E F C
test test D, E, F
F C,F

test
main test
main,A,B,C
test
B
 Risk Driven integration

• Integrate base on criticality

– most critical or complex modules integrated
first with modules called
 Function/thread integration

• Integrate modules according to threads/functions

they belong to

main

A B C

D E F
 Integration of Object-Oriented
Systems
• Different scopes
– Intra Class (methods within a class)
– Big-bang
– Bottom-up: constructors - accessors - predicates - modifiers -
iterators – destructors
– State based integration
– Cluster Integration
– Big Bang
– Bottom-up
– Top-down
– Scenario based
– Subsystem/System Integration
– Big Bang
– Bottom-up
– Top-down
– Use case based
 Intra-Class Integration

• Operations in classes (methods)

– black box, white box approaches
– each exception raised at least once
– each interrupt forced to occur at least once
– each attribute set and interogated at least once
– state-based testing

• Integration of methods
– Big-bang indicated for situation where methods are
tighly coupled
– complex methods can be tested with stubs/mocks
 Cluster Integration

• Needs a class dependency tree

FinancialService

Transaction Account

Rate Money AcctNum

IntCollection
 Cluster Integration
Big Bang approach
• Recommended only when:
– Cluster is stable, only few elements added or
changed
– Small cluster
– Components are very tighly coupled
– Impossible to test separately in practice
 Cluster Integration
Bottom-up approach
• Most widely used technique

• Integrate classes test

IntCollection
test
IntCollection,

– starting from leaves and

Rate

– moving up in
test

– dependency tree
Transaction,
Rate,Money,
test IntCollection
Money test
FinancialService,
FinancialService Transaction,
Account,Money
AcctNum,Rate
Transaction Account test IntCollection
Account,Money
AcctNum
Rate Money AcctNum

test
IntCollection
AcctNum
 Cluster Integration
Top-down Integration
• Possible only when there is a head class

• Example: cluster with façade class

 Cluster Integration
Scenario-based approach
• Scenario
– describes how classes interact
– represented using interaction diagrams

• Approach
1. Map collaborations onto dependency tree
2. Choose a sequence to apply collaborations. For example:
– simplest first
– fewest stubs first
– etc.
3. Develop and run test exercising collaboration
 Cluster Integration
Scenario based approach
• Collaboration 1
– FinancialService,
Transaction, Rate,
FinancialService

InCollection
Transaction Account
– Stubs for: Account,
Money, AcctNum
Rate Money AcctNum
• Collaboration 2
– FinancialService,
IntCollection
Account, Money,
AcctNum
– Stubs for:
Transaction, Rate,
IntCollection
 Problems related to inheritance (1)

• Makes understanding code more difficult

• Instance variables similar to global variables

• Test suite for a method almost never adequate for

overriding methods

• Accidental reuse
– Using an inherited method when it was not
intended to do so.
 Problems related to inheritance (2)

• Multiple inheritance
– Multiple test-cases needed
– Possibility of incorrect binding
– Repeated inheritance

• Abstract classes
– Cannot be instantiated directly.

• Generic classes
 Example

public class Account extends Object • Coincidental correctness

{
protected Date lastTxDate, today; possible
int quartersSinceLastTx()
{ • Necessity to test inherit
return (90/daysSinceLastTx());
} method in the context of
int daysSinceLastTx() inheriting classes
{
return (today.day() - lastTxDay.txDate + 1);
// Correct - today's transaction return 1
// day elapsed
}
}
public class TimeDepositAccount extends Account
{
int daysSinceLastTx()
{
return daysSinceLastTx(today.day() -
lastTxDay.txDate);
// Incorrect - today's transactions
// return 0 days elapsed
}
}
 Subsystem/System Integration

• Big Bang integration

– not generally recommended

• Bottom-up integration
– works well for small/medium systems

• Top-down integration

• Use case based integration

– based on high-level (external) use cases
 Client/Server integration
Two tier System
• Test each client with stubs for servers

• Test server with stubs for each client types

• Test pairs of client type with the actual server

(server may have stubs for the other clients)

• Remove all stubs and test server with clients

client 1 client 3

server

client 2 client 4
 Client/Server integration
Three-tier System
• Test each client with stubs for servers, and the middle-tier.
• Test server with stubs for each client types, and the middle-tier.
• Test each client with middle-tier and server proxy.
• Test server with middle-tier and client proxy.
• Test clients with middle-tier and the actual server.

client client client client

1 2 3 4

Middle Tier

server