Automating Interaction Testing with UML Sequence Diagrams: Where TDD and UML meet

3,673 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,673
On SlideShare
0
From Embeds
0
Number of Embeds
50
Actions
Shares
0
Downloads
60
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Automating Interaction Testing with UML Sequence Diagrams: Where TDD and UML meet

  1. 1. 1 AGILE PORTUGAL 2010 AUTOMATING INTERACTION TESTING WITH UML SEQUENCE DIAGRAMS: WHERE TDD AND UML MEET João Pascoal Faria (jpf@fe.up.pt) 25 July 2010
  2. 2. The problem 2 The development of computer-based UML (OO) design models used as documentation only is time consuming the result is often wrong the result soon becomes outdated This is a concern both for Educators/students: effective teaching/learning OOD Professionals: cost-effective & agile development of high-quality software
  3. 3. Possible solutions 3 Not using UML Paper/hand drawings Fast, but difficult to verify and maintain Good for initial thinking Reverse engineering (from code to models) Fast, ensures consistency, difficult to abstract details away May be good for documenting but not doing the design Automatic code/test generation from models (MDD/MBT) Time invested can be recovered The quality of the models can be checked and improved There is a good chance that they are kept up-to-date All 3 important, can be used in combination, focus here on the last one
  4. 4. What UML diagrams? (1/2) 4 Focus here is in detailed/OOD (classes) Not architectural design (components, etc.) Structure/syntax: class diagrams Generation of compile-ready class skeletons supported by most UML tools A limited but successful form of MDD
  5. 5. What UML diagrams? (2/2) 5 Behavior/semantics: sequence diagrams first Captures the essence of object behavior: message exchange among objects Nice fit for iterative dev. of use cases/scenarios/user stories Simple completeness/done/consistency criteria wrt class diagrams: using all classes and public methods Good for specifying gray-box tests (unit & interaction): instead of full heavy-weight behavior spec, partial light-weight behavior spec through test specs Need tools for generating test code (e.g., xUnit) from sequence diagrams Check that interactions among objects occur as specified A limited but viable form of MBT
  6. 6. The proposed solution 6 4 Complete method bodies (code) Enterprise Architect (EA) code generator Java Classes UML Class Uses Java (compile ready, Diagrams empty methods) Libraries 2 1 6 refactor design Traces execution Tests 7 iterate of methods & constructors 1 2 New Add-in for EA UML Test generator Trace JUnit tests Utilities Sequence Diagrams New Uses (AspectJ) 3 5 Test results
  7. 7. Enterprise Architect Add-In 7 COM+ component developed in C# Interacts with EA through its Object-Model (gives access to the model elements) Generates JUnit source files from sequence diagrams (test specs) User only has to choose destination directory
  8. 8. Test organization 8 package spreadheettest; import junit.framework.TestCase; public class SpreadsheetAppTest extends TestCase { public void testCalculatedField() {…} } package spreadheettest; import junit.framework.TestCase; public class SpreadshhetTest extends TestCase { public void testCalculatedField() {…} public void testCircularReference() {.} } Each sequence diagram generates one test method Test classes & packages generated according to hierarchical model organization.
  9. 9. Simple API black-box testing 9 Constructor call public void testCalculatedField() { Spreadsheet s0 = new Spreadsheet("s0"); Method call and return assertEquals("s0", s0.getName()); … }
  10. 10. Checking internal interactions 10 … Trace.start(); Cell x = new Cell("x", s0); Trace.check( new Call("Spreadsheet", s0, "addCell", new Object[] {x}, null, null)); … expected target target method parameters return nested internal call(s) class object value calls
  11. 11. Internal object creation & checking 11 return parameters creation
  12. 12. Internal object creation & checking 12 Stores a reference to the actual object (initially null), which is assigned on first checking, and compared/tested on subsequent ones (by Trace.check). … ObjectHandler r = new ObjectHandler(); ObjectHandler c = new ObjectHandler(); ObjectHandler a = new ObjectHandler(); Trace.start(); y.setFormula("x + 1"); Trace.check( new Call("Parser", null, "parse", new Object[] {s0, "x + 1"}, a, new Call[] { new Call("CellReference", r, "CellReference", new Object[] {x}, null, null), new Call("Constant", c, "Constant", new Object[] {1.0}, null, null), new Call("Add", a, "Add", new Object[] {r, c}, null, null)})); … check call on check parameters check return of internal object as internal objects internal object
  13. 13. Call tree checking 13 The actual call tree must be a super-tree of the specified/expected call tree Violations checked: absence of call, bad parameters, bat target object, bad return values Intermmediate method calls (for example auxiliary methods) are allowed Allows focusing the specification on the relevant interactions (need not be a fully heavy-weight) specification
  14. 14. Exceptions 14 try { x.getValue(); fail(“Should have thrown CircularReferenceException"); } catch(CircularReferenceException exception) { }
  15. 15. User Interaction - Modeling 15 With “main”, provides a simple spreadsheetengine::SpreadsheetApp command line interface User start() Spreadsheet("s") s :Spreadsheet start (application) and enter (data) are keywords that enter("x = 1") represent user actions x :Cell Cell("x", s) setFormula("1") system displays information enter("x + 1") to the user getValue() 1.0() "2.0"() Illusion of user in control: user enter("") action/system response User and system run concurrently User interaction Internal interactions
  16. 16. User Interaction – Test generation (Internal interaction checking ommited for simplification reasons) 16 public void testCommandLineInterface { starts console simulator Console.start(); Thread thread1 = new Thread() { start() public void run() { SpreadsheetApp.main(null); } enter("x = 1") }; thread1.start(); enter("x = 1") Console.enter("x = 1"); enter("x + 1") Console.enter("x + 1"); "2.0"() assertEquals("2.0", Console.check()); enter("") Console.enter(""); thread1.join(1000); wait for system termination assertFalse(thread1.isAlive()); finishes console simulator Console.stop(); }
  17. 17. User Interaction Testing – Console 17 Simulator “around” advice redefines console I/O behavior Currently only output via java.io.PrintStream Currently only input via java.util.Scanner Two Java LinkedBlockingQueue’s are used for communication data between system and test code “around” advice redirects input/output calls to these queues Handles synchronization (blocking until data is available) Handles timeouts (maximum wait time) Application is developed normaly
  18. 18. Conclusions 18 Approach supports lightweight behavior spec through sequence diagrams as test specs Test code is automatically generated from sequence diagrams Supports effective combination of agile modeling and TDD (test-driven development) Quality of models is tested
  19. 19. Future Work 19 Better fault localization and messages Multiple system behaviors allowed Improving user interaction testing Distributed and concurrent systems Multiple programming languages Circumvent some Enterprise Architect limitations
  20. 20. Thank You

×