StateBased Incremental Testing of AspectOriented Programs

1
State-Based Incremental Testing of
Aspect-Oriented Programs

• Dianxiang Xu and Weifeng Xu
• North Dakota State University, USA
• Presented by Jianjun Zhao

2
Outline

• Introduction
• Related Work
• Aspect-Oriented State Models
• Incremental Testing
• Detecting Aspect Faults
• Conclusions

3
What Is the Work about?

• Keyword 1 AOP Testing
• New programming constructs introduce many
  opportunities of potential aspect faults
• Examples Incorrect pointcut and advice
• Keyword 2 Incremental Testing
• Aspects as incremental modification of classes
• We test base classes first, and then aspects
• If base classes pass all tests, but aspect
  -oriented program as a whole fail some tests, the
  failure would have to do with aspects.

4
What Is the Work about? contd

• Keyword 3 State-Based
• Abstract state models for aspects and classes
• Research Issues
• How to specify the expected impact of aspects on
  object states for test generation purposes?
• To what extent can base class tests be reused for
  testing aspects?
• Base class tests may not be valid for aspects if
  aspects change transitions of object states.

5
Our Approach

• Developing an aspect-oriented extension to state
  models with testability
• Formalizing an explicit weaving mechanism for
  composing aspect models with class models
• Adapting the round-trip test strategy to aspect
  testing
• Identifying rules for reuse of base class tests
  for aspect testing
• Investigating the impact of aspect faults on
  state/transition of objects

6
Related Work

• Testing of AOP
• Data flow based (Zhao et al. 2003)
• Control flow based (Zhou et al. 2004)
• Test generation and framework (several papers at
  AOSD05 WTAOP)
• Fault model (Alexander et al. 2004)
• Our approach model-based test generation
  (blackbox)

7
Related Work contd

• Aspect-Oriented Modeling
• Existing formalisms
• UML dominant approach (AOM Workshop series)
• Statecharts (Elrad, Aldawud, et al. 2002-05)
• Petri Nets (Xu et al., IEEE TSE, 2006)
• This paper testabilityexplicit weaving
  mechanism
• Different purposes of modeling
• Design specification (majority), code generation,
  reverse engineering.
• This paper test generation

8
State Models

• S a set of states (i.e. abstract object states)
• E a set of events
• Constructors and methods
• V a set of variables (for spec of guards)
• Instance variables, parameters of constructors
  and methods
• T a set of transitions
• Transition (si, e, ?, sj) event e transforms
  state si to state sj under guard condition ?.

9
State Model of BankAccount
10
Aspect-Oriented State Models

• Join Points
• States, events, or variables in the state model
  of a base class
• Pointcuts
• Each pointcut picks out a group of join points
• Advices
• Each advice is a state model
• Aspects
• An aspect is an encapsulated entity of pointcuts
  and advice model.

11
Pointcut Expression

• State pointcut
• ltcutnamegtltbase-modelgt.ltstategt
• Event pointcut
• ltcutnamegt ltbase-modelgt.ltevent(paras)gt
• Variable pointcut
• ltcutnamegt ltbase-modelgt.ltvariablegt

12
Aspect Model

• State pointcuts
• Event pointcuts,
• Variable pointcuts
• Advice state model
• An advice model is not necessarily strongly
  connected
• It may contain the sub-models of all advices

13
Aspect Example Overdraft

• Enforces a new policy for BankAccount
• Allows one overdraft as long as the balance is
  not less than -1000.
• Impacts
• New state Overdrawn
• New transitions associated with Overdrawn
• Modified transitions due to Overdrawn

14
Overdraft Model
state pointcut Open BankAccount.Open event
pointcut get BankAccount.getBalance event
pointcut debit(x) BankAccount.withdraw(amt) event
pointcut credit(x) BankAccount.deposit(amt) vari
able pointcut b BankAccount.b
15
Weaving Overdraft with BankAccount
16
Impacts of Aspects on Base Models

• Adding new transitions among existing states to
  the base models
• Introducing new states and thus new transitions
  to the base models (e.g. Overdraft)
• Removing transitions from the base models
• Modifying guard conditions of transitions in the
  base models
• Introducing new events to the base models (e.g.
  via inter-type declarations).

17
Semantics of Aspect Models

• Pointcuts
• A naming mechanism
• Advice models
• Override the corresponding part in the base model
  according to the naming mechanism (i.e. state,
  event and variable pointcut specifications)

18
The FooBar Example

• From the aspectprogrammer.org forum
• In the FooBar base class
• No constraint on the order in which methods foo
  and bar are called.
• Use an aspect to enforce the policy that foo
  always comes before bar
• Every call to bar must be preceded by at least
  one call to foo.
• After any call to bar, foo must be called at
  least once before bar can be called again.

19
The FooBar Example contd
20
FooBar The Woven Model
21
Incremental Testing Process

• Test Base Classes
• Build the state models
• Generate abstract test cases from models
• Derive concrete test suites
• Test Aspects
• Build aspect models
• Wave them into the base models
• Generate abstract tests from woven models
• Generate test suites by reusing, modifying, and
  extending concrete base class tests
• Instantiate new abstract tests

22
Test Generation from State Models

• Binders Round Trip Path Testing
• Generate the transition tree from state model
• Each path from the root to a leaf is an abstract
  test method
• Positive vs. Negative Tests

23
Why Reuse Base Class Tests for Aspects?

• Tests generated from state models are abstract
• No variables in constructors/methods are bound
• Concrete test cases are derived by assigning
  appropriate values to the variables.
• Must satisfy all guard conditions in the path
• The derivation is a undecidable problem!
• We derive concrete tests by hand.
• Expensive investment!
• Reuse is believed to significantly reduce test
  cost.

24
Rules for Reuse

• Rule 1 Full reuse of positive tests
• A positive base class test remains as a positive
  test for the aspect-oriented program.
• Rule 2 Full reuse of negative tests
• A negative base class test remains as a negative
  test for the aspect-oriented program.
• Rule 3 Modified reuse of positive base class
  tests as negative aspect tests.
• Rule 4 Reuse of negative tests for expansion.
• A negative base class test can be expanded to
  either positive or negative tests
• More details are in the paper.

25
Test Tree for the Woven FooBar Model
Negative Tests ltnew, START, bar, STARTgt ltnew,
START, foo, FOO, bar, BAR, bar, BARgt. They are
positive tests for the base FooBar
class. Positive Base Class Tests Become Negative
Aspect Tests.
26
Tests for the BankAccount Example

• Negative base class test can become positive
  aspect tests
• ltnew, Open, withdrawb-amtlt0, Opengt where
  b-amtgt-1000 is a negative test for BankAccount
  alone
• gt
• ltnew, Open, withdrawb-amtlt0 and b-amtgt-1000,
  Overdrawngt is a positive test for BankAccount
  class Overdraft aspect

27
Detecting Aspect Faults

• Fault Model
• Pointcuts picking out extra join points
• Pointcuts missing join points
• Incorrect advice types
• Incorrect advice implementation
• Fault Seeding one fault in each faulty version
• FooBar and BankAccount
• Testing Results
• All faults were detected
• Why each led to an unexpected state.

28
Contribution of the Work

• Rigorous aspect-oriented extension to state
  models with an explicit weaving mechanism
• Investigation of reusing base class tests for
  testing of aspect-oriented programs.
• Rules of reuse
• Subtle modifications to base class tests may be
  needed.
• In particular, positive (or negative) base class
  tests can become (part of) negative (or positive)
  aspect tests.

29
Issues for Future Work

• What kind of base class tests are less likely
  helpful for revealing aspect faults?
• How to prioritize the test cases to be reused?
• How to model and test interference of multiple
  interacting aspects?

30
Thank You!

• Questions can be directed to
• dianxiang.xu_at_ndsu.edu
• Department of Computer Science
• North Dakota State University
• Fargo, ND 58105, USA