(c) 2002 Object Mentor, Inc.1 Testing Things That Seem Hard To Test Robert Koss, Ph. D. ObjectMentor, Inc.

(c) 2002 Object Mentor, Inc.2 Introduction XP dictates that we test everything that can possibly break –Subjective accessors and mutators What if mutator does validation? How much logic is too much? What if class Foo is difficult to test? FooTestFoo

(c) 2002 Object Mentor, Inc.3 Sources of Difficulty Some objects appear to be difficult to test –Objects which depend upon other objects. –GUI’s –Databases –Servlets / EJB’s What makes these things hard to test? –Not knowing what to test –Source code dependencies Collaborating objects

(c) 2002 Object Mentor, Inc.4 Knowing What to Test GUI –Assume Swing / MFC works –Model-View-Controller Make sure anything that can break is in a class which can be tested Databases –Assume Oracle / SQL Server, etc. works Servlets –HttpUnit –Delegate to a class which can be tested.

(c) 2002 Object Mentor, Inc.5 Collaborating Objects Mark IV Coffee Maker public void testMakeCoffee() { CoffeeMaker cm = new CoffeeMaker(); cm.makeCoffee(); assert( ? ? ? ); }

(c) 2002 Object Mentor, Inc.6 Breaking Troublesome Dependencies A source-code dependency can always be broken by the judicious use of an interface. Dependency has been inverted –Both A and B now depend upon an interface A no longer knows concrete type of B –Can now test A by supplying a MockB

(c) 2002 Object Mentor, Inc.7 Mock Objects / Stubs Class A can’t tell if message goes to class B or class BStub Class BStub used to create testing environment, totally under control of class ATest

(c) 2002 Object Mentor, Inc.8 Self-Shunt Pattern Not always necessary to make a new class and create a new object for Bstub Class ATest can implement the IB interface

(c) 2002 Object Mentor, Inc.9 CoffeeMakerTest Stub out Warmer and Boiler

(c) 2002 Object Mentor, Inc.10 Stubs Everywhere ? Stubs are good when real class can’t easily be used –Hardware –Database –Dependent class not done Not necessary for Value Objects Not necessary if dependants are known to work

(c) 2002 Object Mentor, Inc.11 Chains of Dependencies Bowling Game Boom, Splash, (x, y, z, t)

(c) 2002 Object Mentor, Inc.12 More Uses for Stubs Logging –When object under test is supposed to send a sequence of messages to another object in a specific order –Record message sent as a string append to string for each message –Alternative to setting several flags and examining in test

(c) 2002 Object Mentor, Inc.13 More Uses for Stubs Null Object Pattern –When doing nothing is the right thing to do –Don’t have to test for presence of Logger object

(c) 2002 Object Mentor, Inc.14 Testing GUI’s Test Model (MVC) first –Concentrate on business instead of user interface –Start just inside the UI –Quicken addCheck( new Check( checkNum, payee, amount)) is more important than a fancy check gui Same with reconcile()

(c) 2002 Object Mentor, Inc.15 Testing GUI’s Decide what to test –Can test everything except for aestetics –Should we? public void testWidgetsPresent() { SearchPanel panel = new SearchPanel(); assertNotNull(panel.searchLabel); assertNotNull(panel.queryField); assertNotNull(panel.findButton); assertNotNull(panel.resultTable); }

(c) 2002 Object Mentor, Inc.16 Being Pragmatic Assume GUI toolkit works –Swing, MFC, Qt, GTK –new Button( “OK”); Continually ask if code being written can possibly break Continually ask if code being written is doing more than UI Make sure all logic is in classes that can be tested Make GUI code so thin that it can’t possibly break.

(c) 2002 Object Mentor, Inc.17 Separate Domain From User Interface Model - View - Controller Document - View –Combines traditional View with Controller –Good unless several Controllers are needed Model - View - Presenter – 106.ibm.com/developerworks/library/mvp.html –Combines traditional View with Controller –Adds another layer between UI and Model –Presenter is ideal place to do unit testing of GUI

(c) 2002 Object Mentor, Inc.18 Single Responsibility Principle A class has a single responsibility. It meets that responsibility, the whole responsibility, and nothing but that responsibility –Called cohesion in Structured Design Applied to functions –Rule of thumb Describe class’s responsibility without using “and” What is the responsibility of an event handler? –“Handles” event –Scope of “handle” subjective –Should not have any program logic

(c) 2002 Object Mentor, Inc.19 A Stupid GUI Is an Unbreakable GUI Event handler should do nothing but gather the information from event and delegate responsibility to another class –Can’t possibly break –e.g., MouseEventHandler should get click coordinates and delegate to another class that knows what to do when the mouse is clicked hit testing

(c) 2002 Object Mentor, Inc.20 Event Handlers Dialog / Window with GUI Control and registered listener Testing listener can be –Easy / Annoying –Hard / Impossible How do we test this?

(c) 2002 Object Mentor, Inc.21 Event Handlers Delegate Have event handler delegate to something that can be tested Presenter (MVP)

(c) 2002 Object Mentor, Inc.22 General Architecture Note the direction of the dependencies Make this unbreakable

(c) 2002 Object Mentor, Inc.23 Interacting GUI Components Interaction with one GUI component causes changes to other components. –Menus becoming active / inactive –Toolbar changes Mediator Pattern –Have each event handler delegate to mediator and have mediator determine what else must change –Component interactions now localized (and testable!) instead of being distributed over all event handlers.

(c) 2002 Object Mentor, Inc.24 Mediators as State Machines Using a Mediator localizes inter-object communication Mediators can become ugly for complicated windows Implementing Mediator as a state machine makes it easy to get the wiring correct and to easily accommodate changes

(c) 2002 Object Mentor, Inc.25 Summary We have to test everything that can possibly break If something appears hard to test, don’t let it do anything that can break –Delegate to an object that can be tested