[prev in list] [next in list] [prev in thread] [next in thread] 

List:       extremeprogramming
Subject:    Re: [XP] How do XP teams using FIT acceptance test their GUI layer?
From:       "J. B. Rainsberger" <jbrains () rogers ! com>
Date:       2004-09-29 17:12:00
Message-ID: 415AECE0.5020202 () rogers ! com
[Download RAW message or body]

Ilja Preuss wrote:
> Ken Boucher wrote:
> 
>>I understand that the GUI layer for such teams is very thin, and to
>>me that makes good sense twice, since I can understand a desire to
>>keep as much logic in the model as possible.
> 
> Sadly, I'm currently (part time) working on a legacy app where the GUI
> layer is tightly coupled not only to the "model", but in fact to the
> database (using Borland DataExpress).
> 
> So most of our Fit(Nesse) test actually go through the GUI. I've written
> Fixtures using JfcUnit to do this - it's available at
> http://sf.net/projects/jfcfixtures - no official release or docu yet,
> though.

I treat Fit as another UI using the same application. When I test a UI, 
I do so independently of the application the UI drives. This means in 
particular that my Fit tests test the application, rather than the UI.

Faced with your situation, I simply parameterize methods like crazy, 
passing in Database interfaces where possible. After that, I might pull 
the parameterized methods out into a new class that doesn't depend at 
all directly on the Database. Now I am much closer to testing them in 
isolation. It's worth the pain for me.

>>However, how do XP teams that use FIT test their GUI layer? Manually?
>>Automated? Unit test only? Record/Replay?
> 
> What I'd like to know is: What is the best way to mock the model when
> testing the GUI with Fit?

It's not necessarily the best way, but...

To me, a GUI is a widget layer that talk through a protocol to an 
application. That protocol is often text based (since I'm a web guy, and 
on the web all the world's a string). The widget layer's job, then, is 
to translate user gestures into a text request that matches the 
protocol. If you do this, and if the widget layer talks to the protocol 
through an interface, then simply parameterize the constructor of the 
GUI's entry point.

public class ApplicationGuiEntryPoint {
     private ApplicationProtocol applicationProcotol;   // interface

     public ApplicationGuiEntryPoint(ApplicationProtocol 
applicationProtocol) {
         this.xxx = xxx;
     }

     ...

     public static void main(...) {
         new ApplicationGuiEntryPoint(new RealApplicationProtocol()).go();
     }
}

In your tests, pass in whatever test double for the application protocol 
you need. You can parameterize the constructor of your custom widget 
classes (if any) the same way.

If you want to test with FIT, then create a fixture that describes the 
implementation of ApplicationProtocol you want to use for the current 
test document.

|ApplicationProtocolInstallerFixture|
|com.mycompany.myapp.protocol.FakeApplicationProtocol|

If you want to get fancy, expose some of the "fakeness" of your 
FakeApplicationProtocol to the installer fixture so you can configure 
the fake object right inside your Fit test.

Neat.
-- 
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery


To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[prev in list] [next in list] [prev in thread] [next in thread]