081107 Sammy Eclipse Summit2

1,066 views

Published on

Testing Eclipse GUIs still is an elaborate and extensive task. There are two ways to get the task done: Record-and-play and programming by hand. Test-first programmers usually prefer to program their tests by hand instead of using record-and-play tools, which are typically used by test departments that construct large functional test suites.
When programming UI tests by hand, the programmer is let alone mainly with SWT Robots. While they are great tools to find and use widgets, they naturally can't find their controllers like the the JFace Viewers and the Workbench ViewParts. In test-first development this becomes a problem because the programming level for test and productive code is at a different abstraction level.
Matthias Kempka has found a way to implement a JFace/Workbench Robot. It finds JFace Viewers for SWT elements and eases the testing with views and editors. Declarative UI Elements become accessible for programmed tests. In his talk Matthias Kempka shows how he uses the JFace/Workbench Robot to develop GUI components in Eclipse test-driven and gives an introduction to the key ideas that make the Robot work.

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

No Downloads
Views
Total views
1,066
On SlideShare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
17
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

081107 Sammy Eclipse Summit2

  1. 1. Enabling Test-First Development for Eclipse UI Matthias Kempka Innoopract Informationssysteme GmbH
  2. 2. Outline  Problem description  Components for testing UI programmatically  Test Case with JFace/Workbench Robot Sammy
  3. 3. Creating code test-driven  TDD creates little pieces of code  Readable  Simple  Flexible  Regression tests already there  Great, uh? Unit Tests Piece of Code
  4. 4. Where should I put it?  A framework has many hooks  Did I hook up my PoC in the right spot?  Did I hook it up at all? Eclipse Framework Piece of Code
  5. 5. „Testing“ by hand  Easiest approach: Try it.  Regression tests? *click* Developer use Eclipse Framework Piece of Code
  6. 6. PDE Tests  Let's write regression tests  PDE tests can start our test code with a workbench  Some Eclipse functionality is hard to reach programmatically PDE Unit Tests Eclipse Framework Piece of Code
  7. 7. Functional Tests with SWT Robots  SWT Robots can simulate User interaction  Is it easier to find a ViewAction button on the screen than in the Workbench API? PDE Unit Tests use SWT *click* Robot use Eclipse Framework Piece of Code
  8. 8. Are SWT Robots the solution?  Can find SWT widgets in the widget hierarchy  Provides convenience methods to use the widgets  Can read feedback from the UI Display Shell Composite Label Text
  9. 9. What's not in the Widget Hierarchy?  Basically all objects an Eclipse programmer touches are not in the widget hierarchy  Association with IDs from plugin.xml is lost Display IViewPart IActionDelegate Shell IMarker IEditorPart Composite TreeViewer IHandler Label Text TableViewer ...
  10. 10. Functional Tests with Robots  A JFace/Workbench Robot eases access to the interesting parts of the UI.  Provides access to JFace controllers SWT Robot *click* PDE Unit Tests JFace/Workbench Robot use Eclipse Framework Piece of Code
  11. 11. Sammy: The Mission Make common things easy, make difficult things possible  I need to set up test data for the TableViewer behind this SWT Table on the screen? How can I reach it?  I'm writing a view. How can I test that all the listeners are attached correctly?  I'm writing a contribution to a view (i.e. a ViewAction) – How can I test that my entries in plugin.xml works?  Does my LabelProvider return the right image?
  12. 12. Writing a test with JFace/Workbench Robot Sammy Write a test case:  Set up: Prepare a view for the actual test – open the view  Tear down: – Clean up allocated resources: Close the view  Actual test – Find the TableViewer in that view and set a test-specific input – Check that a view action is not enabled – Select an item in the table – Check that the view action is enabled
  13. 13. Set up: Open a view  Views could be opened using IWorkbenchPage.showView( id ) – Too cumbersome for such a common use case – No immediate feedback on errors  Sammy.openView( id ) eases setting up test cases – easy accessible API – Show errors in red test case instead of UI – Remembers the view for cleaning up public void setup() throws Exception { sammy = new Sammy(); sammy.openView( ViewUnderTest.ID ); }
  14. 14. Tear down  Instances of Sammy (and SammyIDE) remember the resources they allocated and can release (close or delete) them – IViewPart – IEditorPart – IResource public void teardown() throws Exception { sammy.cleanup(); }
  15. 15. Test: Finding the view  Every supported JFace/Workbench Element has an Operator: – IViewPart – ViewOperator – IEditorPart – EditorOperator – TableViewer – TableViewerOperator – …  The Operator gives access to the described JFace/Workbench element – Convenience methods for common use cases  Operator constructor – takes parameters that describe the JFace/Workbench element – returns without Exception only if the described element was found – waits a time for the element to appear public void testViewAction() throws Exception { ViewOperator vo = new ViewOperator( “View Title” ); }
  16. 16. Test: Finding the TableViewer  Operators for workbench parts know their parent composite – Given in IWorkbenchPart.createPartControl( Composite )  Operators for JFace elements – take a parent of the SWT element or the SWT element itself – can associate the SWT element with the JFace abstraction public void testViewAction() throws Exception { ViewOperator vo = new ViewOperator( “View Title” ); TableViewerOperator tvo = new TableViewerOperator( vo.getParentComposite() ); }
  17. 17. Test: Setting the Input  Setting up Test Data often includes setting a special input on a viewer  Having the TableViewer already available eases this remarkably  *Operator.getSource()returns the actual JFace/Workbench element public void testViewAction() throws Exception { ViewOperator vo = new ViewOperator( “View Title” ); TableViewerOperator tvo = new TableViewerOperator( vo.getParentComposite() ); tvo.getSource().setInput( new String[] { “a” } ); }
  18. 18. Test: Checking ViewerOperator enablement  A ViewActionDelegate only is instanciated once the user selects the ViewAction  The ViewActionOperator knows the Proxy by the workbench as well as the delegate public void testViewAction() throws Exception { ViewOperator vo = new ViewOperator( “View Title” ); TableViewerOperator tvo = new TableViewerOperator( vo.getParentComposite() ); tvo.getSource().setInput( new String[] { “a” } ); ViewActionOperator vao = new ViewActionOperator( vo, MyViewAction.ID ); assertFalse( vao.isEnabled() ); }
  19. 19. Test: Checking ViewerOperator enablement  Now all the elements are in place to make this test useful – The View shows up (layout is not tested) – XML Code in plugin.xml is tested – Makes sure that the TableViewer is a SelectionProvider public void testViewAction() throws Exception { ViewOperator vo = new ViewOperator( “View Title” ); TableViewerOperator tvo = new TableViewerOperator( vo.getParentComposite() ); tvo.getSource().setInput( new String[] { “a” } ); ViewActionOperator vao = new ViewActionOperator( vo, MyViewAction.ID ); assertFalse( vao.isEnabled() ); tvo.getSource().setSelection( new StructuredSelection(“a”)); assertTrue( vao.isEnabled() ); }
  20. 20. Sammy Internals  For many things, Sammy relies on mapping from widgets to JFace/Workbench elements – And vice versa  Some widgets are nowhere accessible in the workbench – Where necessary aspects are used to trap widget instances  For some things, Sammy has to access internals – i.e. the View that shows an error holds it in a private field – This leads to compatibility layers, but at least it's in one place Widget Viewer
  21. 21. Sammy Future  More than proof of concept, less than beta  A good state to start collecting requirements  http://www.innoopract.com/en/developers/mkempka/sammy
  22. 22. The End http://www.innoopract.com/en/developers/mkempka/sammy

×