Test Driving Your S-Wing By Patrick Kua emailpat <at> thekua.com || pkua <at> thoughtworks.com

The Agenda

Unit Integration Tests x 10 Unit Tests x 100s Unit Integration Tests x 10 Acceptance Tests x1 0010110101010110 1010001011010101 1010100010110101 0101101010001012 1010101011010100 1011010101011100 1010001011000010 Code Developer Loop

Writing Acceptance Tests You need objects that describe parts of the application – based on screens, dialogs, fields and various other parts It’s important to name things they way that the business would so that you can share tests with them and verify that they are working as expected Try to focus on the things the application should do, push the how into the ‘Screen Objecfts’ that you will create You should end up with a DSL group of objects that can be reused across acceptance tests, and hopefully don’t need to add too much too If needed, don’t expose more things that you need to from the page objects Leverage Standard Tools If your project is used to FIT, use that for communicating for the business JUnit means that you’ll probably be able to focus more on the screen objects and refactor things where appropriate Writing Acceptance Tests

As an author I would like to be prompted for confirmation on exit so that I do not lose any unsaved changes Confirm Exit

VS Source Test

public void testOnExitIAmAskedForConfirmation() { MainApplication application = TestHelper.getMainApplication(); ConfirmationDialog dialog = application.clickExit(); assertNotNull(dialog); assertEquals(“Are you sure you want to Exit?”, dialog.getMessage()); dialog.clickCancel(); assertTrue(application.isShowing()); }

How To Implement No Frameworks (yay!) Model View Presenter Test Things Only Worth Testing Unit Test as Much as Possible Code Changes Based on Tests Demonstration… For implementing a TDD-ed applciation, we’re going to avoid any frameworks because there are not many out there that are worth using and also many of them don’t really promote TDDing The MVP presenter pattern is used to help separate the tesitng aspect of this: The view is a very thin veneer that the presenter is interacting with The view should be a single line of delegation Layout is not really worth testing – it’s much easier to play with the layout aspect if you don’t care too much where everyhting is placed

How it all works (Yawn… I mean Architecture) Layout Managers Presenters Glue Views Repository

Implementing Confirmation of Exit Actually Exit

Abbot & Costello Alternatives include: Marathon Man Jemmy (Netbeans) http://marathonman.sourceforge.net Jemmy (Netbeans) http://jacareto.sourceforge.net Jacreto JFC Unit http://jfcunit.sourceforge.net Pounder http://pounder.sourceforge.net http://abbot.sourceforge.net/

Robust Acceptance Tests

Top Tips Top Tips: Give every important component a name that will be unique so that you can more easily find them. Even given panels a component if it helps make another component more useful (i.e. description field on one screen might mean something else) Separate everything that you can into its own testable POJO and only interact with the view if you really have to. Use the presenter to shield the model from the view if you want to maek it more testable (an interface will help you to mock these interactions easier) High discipline will be required too maintain a fully TDD-ed application The view should be extremely thin (one line of delegation) Split the responsibility – the presenter interacts with more complex objects that have business purpose (it’s just a layer that represents the veiw) Getting around threading issues At some point, you’re going to have to use the SwingUtilities to do a wait() or something oepration. We introduced an application event queue interface that allowed us to inject something for tests so that we could predictably run tests Small, reusable objects are much better than large ones (but this holds true for any other systems) When you can use this technique The techniques described here was used on a Greensfield project, but the same principles could be applied if you are working on an existing system, but will be harder (just like working with many TDDed applications) If you have control of the application that you are testing (of course you should, if you are developing it) In refactoring an existing system, it might be better to start giving things names, so that you can write smaller integration tests. When does this testing strategy fail: Everyone has to have very high discipline for TDDing all of the components

Questions? The resources for this presentation can be found at: http://www.thekua.com/conferences/xp2006 Questions?