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

2. The Agenda

3. Unit Integration Tests x 10
Unit Tests x 100s
Unit Integration Tests x 10
Acceptance Tests x1
Code
Developer Loop

4. 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

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

6. VS
Source
Test

7. 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()); }

8. 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

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

10. Implementing Confirmation of Exit
Actually Exit

11. Abbot & Costello Alternatives include: Marathon Man Jemmy (Netbeans)
Jemmy (Netbeans)
Jacreto
JFC Unit
Pounder

12. Robust Acceptance Tests

13. 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

14. Questions? The resources for this presentation can be found at:
Questions?