Testing things that seem hard to test
1 / 25

Testing Things That Seem Hard To Test - PowerPoint PPT Presentation

  • Uploaded on

Testing Things That Seem Hard To Test. Robert Koss, Ph. D. ObjectMentor, Inc. koss@objectmentor.com www.objectmentor.com. Introduction. XP dictates that we test everything that can possibly break Subjective accessors and mutators What if mutator does validation?

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Testing Things That Seem Hard To Test' - benjamin-gonzales

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Testing things that seem hard to test

Testing Things That Seem Hard To Test

Robert Koss, Ph. D.ObjectMentor, Inc.



(c) 2002 Object Mentor, Inc.


  • 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?



(c) 2002 Object Mentor, Inc.

Sources of difficulty
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.

Knowing what to test
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.

Collaborating objects
Collaborating Objects

  • Mark IV Coffee Maker

public void testMakeCoffee() {

CoffeeMaker cm = new CoffeeMaker();


assert( ? ? ? );


(c) 2002 Object Mentor, Inc.

Breaking troublesome dependencies
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.

Mock objects stubs
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.

Self shunt pattern
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.


  • Stub out Warmer and Boiler

(c) 2002 Object Mentor, Inc.

Stubs everywhere
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.

Chains of dependencies
Chains of Dependencies

  • Bowling Game

  • Boom, Splash, (x, y, z, t)

(c) 2002 Object Mentor, Inc.

More uses for stubs
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.

More uses for stubs1
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.

Testing gui s
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.

Testing gui s1
Testing GUI’s

  • Decide what to test

    • Can test everything except for aestetics

    • Should we?

  • http://users.vnet.net/wwake/xp/xp0001/

public void testWidgetsPresent() {

SearchPanel panel = new SearchPanel();






(c) 2002 Object Mentor, Inc.

Being pragmatic
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.

Separate domain from user interface
Separate Domain From User Interface

  • Model - View - Controller

  • Document - View

    • Combines traditional View with Controller

    • Good unless several Controllers are needed

  • Model - View - Presenter

    • http://www-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.

Single responsibility principle
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.

A stupid gui is an unbreakable gui
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.

Event handlers
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.

Event handlers delegate
Event Handlers Delegate

  • Have event handler delegate to something that can be tested

Presenter (MVP)

(c) 2002 Object Mentor, Inc.

General architecture
General Architecture

  • Note the direction of the dependencies

Make this


(c) 2002 Object Mentor, Inc.

Interacting gui components
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.

Mediators as state machines
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.


  • 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

(c) 2002 Object Mentor, Inc.