Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

fitnesse

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 3719
  • Category: Testing
  • Founded: Feb 26, 2003
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 409 - 438 of 20121   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#409 From: Robert Martin UncleBob <UncleBob@...>
Date: Tue Jul 1, 2003 7:37 pm
Subject: Now we know.
rmartinoma
Send Email Send Email
 
This has nothing to do with FitNesse, but it's just too good to pass up.

Now we know what God thinks of us.

http://antwrp.gsfc.nasa.gov/apod/ap030630.html?list=true

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15
565 Lakeview Pkwy   | Fax: (847) 573-1658
Suite 135           |
Vernon Hills, IL,   | www.objectmentor.com
60061               |
-----------------------------------------------

#410 From: "vinn01" <vinn01@...>
Date: Tue Jul 1, 2003 7:45 pm
Subject: Why does my WATT test need an html element?
vinn01
Send Email Send Email
 
I started playing around with WATT.  The example at
http://fitnesse.org/FitNesse.SuiteAcceptanceTests.HtmlTests.FrontPageT
est?test

has no html element, just head and body...

|!-HtmlFixture-!|
|http://www.fitnesse.org/FrontPage|
|Elements|2|
|Element|1|head|headElement|
|Element|2|body|bodyElement|
|Element|mainTable|table|mainTableElement|

But when I try to duplicated it, I have to have an html element...

|!-HtmlFixture-!|
|http://www.fitnesse.org/FrontPage|
|Elements|1|
|Element|1|html|htmlElement|

|!-HtmlFixture-!|
|htmlElement|
|Elements|2|
|Element|1|head|headElement|
|Element|2|body|bodyElement|

Why?

Vinn


PS - I'm looking forward to that fixture for testing dynamic client-
side HTML.

#411 From: "Phlip" <plumlee@...>
Date: Tue Jul 1, 2003 9:15 pm
Subject: Driving an IE file browser control from Automation
phlip_cpp
Send Email Send Email
 
Test-firsters:

I cross-posted because it's a hard one! (FitNesse gets this because
someone's doing something similar there, so helping me helps them.)

I'm trying to drive InternetExplorer's Automation model, this time thru
Perl.

(Among other battles, I don't know how to query from Perl the list of
members of an object, or an OLE object.)

The code starts IE as a COM (ActiveX, whatever) object. Then it navigates to
a server (possibly a buggy one!).

The sub findField(type, name) finds an <INPUT> field of the given type and
name.

We find the DOM object fronting this HTML:

     <input size="72" value="" name="file" type="file">

Note the type is "file" - that creates the little "Browse" button that lets
you

Then, we try to change the field's value attribute from nothing to a sample
string...

  # see http://samie.sourceforge.net for more examples of code like this

  use strict;
  use warnings;
  use Win32::OLE qw(EVENTS in);
  use Win32::Process;

  our $IE;

  sub StartIE {
    $IE = Win32::OLE->new("InternetExplorer.Application") || die "Could not
start Internet Explorer.Application\n";
    $IE->{visible} = shift;
  }


  StartIE(1);
  $IE->navigate("http://www.somewhere.com/cgi/service.cgi");

  my $READYSTATE_COMPLETE = 4;

   # while ($IE->{Busy} == 1)
    until($IE->{ReadyState} == $READYSTATE_COMPLETE){
     sleep(0.4);
     }


  my  $IEDoc = $IE->{Document};

  sub findField{
   my $type = shift;
   my $name = shift;
  for (my $i=0; $i < $IEDoc->all->length; $i++) {
   if ($IEDoc->all($i)->tagName =~/^FORM$/) {
    my $form = $IEDoc->all($i);
     for (my $q = 0;  $q < $form->all->length; $q++)
      {

      if ($form->all($q)->tagName =~/^INPUT$/) {
       my $input = $form->all($q);

       if ($input -> {type} eq $type and
         $input -> {name} eq $name )
        {
        return $input;
        }
       }
      }
    }
   }
   return undef;
  }


  my $fileField = findField('file', 'file');
  print $fileField->type."\n";
  print $fileField->name."\n";
  print $fileField->value."\n";
  $fileField->setAttribute('value', "hi mom");
  print $fileField->value."\n";

...every thing there is predictable until after setAttribute(). Then, the
value we push in is not there. When you visually inspect the page, it's
still not there.

I will experiment by writing on fields of type other than "file".

Switching to a legit filename instead of "hi mom" also doesn't work.

--
   Phlip
        http://www.greencheese.org/LucidScheming
   --  Because I'm the sysadmin. That's why.  --

#412 From: "David Hooker" <dhooker@...>
Date: Tue Jul 1, 2003 10:17 pm
Subject: Possible bug?
dudehook
Send Email Send Email
 
In my page, I have the following markup:
 
All files received within the ''do...while'' loop will be stored using the names "reply'''-x'''", where ''x'' is a number corresponding to which pass through the loop the fixture is taking. 
 
If I put two single quotes around the letter x (in red above), it starts an italic section, but the closing two single quotes do not stop the italics, and the entire rest of my page is itallics.  Bold markup does not seem to have this problem.

#413 From: Simon Brown <simes@...>
Date: Wed Jul 2, 2003 8:22 am
Subject: Re: Driving an IE file browser control from Automation
BSLSimes
Send Email Send Email
 
At 14:15 01/07/2003 -0700, Phlip wrote:
>Test-firsters:
>
>I cross-posted because it's a hard one! (FitNesse gets this because
>someone's doing something similar there, so helping me helps them.)
>
>I'm trying to drive InternetExplorer's Automation model, this time thru
>Perl.

<snip>

>...every thing there is predictable until after setAttribute(). Then, the
>value we push in is not there. When you visually inspect the page, it's
>still not there.
>
>I will experiment by writing on fields of type other than "file".
>
>Switching to a legit filename instead of "hi mom" also doesn't work.

If this is anything like driving the DOM through Javascript or JScript, the
security model will not let you programmatically set the contents of a file
upload field. This is to prevent hostile sites using ActiveX controls and
the like to swipe important files from users' systems.

I don't think there's any way around this - given the purpose of the
restriction, there shouldn't be.

Simes.

--
Simon Brown <simes@...>

I could squeeze my lemon 'til my blues went away,
If I had possession over Pancake Day.
                  - Half Man Half Biscuit

#414 From: "Phlip" <plumlee@...>
Date: Wed Jul 2, 2003 12:49 pm
Subject: Re: Driving an IE file browser control from Automation
phlip_cpp
Send Email Send Email
 
> If this is anything like driving the DOM through Javascript or JScript,
the
> security model will not let you programmatically set the contents of a
file
> upload field. This is to prevent hostile sites using ActiveX controls and
> the like to swipe important files from users' systems.
>
> I don't think there's any way around this - given the purpose of the
> restriction, there shouldn't be.
>
> Simes.

It's my browser. Can I turn all the "security" settings off?

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

#415 From: Simon Brown <simes@...>
Date: Wed Jul 2, 2003 12:56 pm
Subject: Re: Driving an IE file browser control from Automation
BSLSimes
Send Email Send Email
 
At 05:49 02/07/2003 -0700, you wrote:
> > If this is anything like driving the DOM through Javascript or JScript,
>the
> > security model will not let you programmatically set the contents of a
>file
> > upload field. This is to prevent hostile sites using ActiveX controls and
> > the like to swipe important files from users' systems.
> >
> > I don't think there's any way around this - given the purpose of the
> > restriction, there shouldn't be.
> >
> > Simes.
>
>It's my browser. Can I turn all the "security" settings off?

You could try adding the site you're testing to the "trusted sites" list -
that might work. Other than that, I dunno.

Simes.

--
Simon Brown <simes@...>

I could squeeze my lemon 'til my blues went away,
If I had possession over Pancake Day.
                  - Half Man Half Biscuit

#416 From: Michael Feathers <mfeathers@...>
Date: Wed Jul 2, 2003 3:29 pm
Subject: Sorry, I just wanted to be the first one to do this..
mfeathers256
Send Email Send Email
 
import java.util.*;
import fit.*;

public class LifeFixture extends Fixture {
     private List birthList;
     private List killList;
     private final static String ALIVE = "X";
     private final static String DEAD = " ";

     boolean isAlive(Parse cell) {
         return cell != null && cell.body.equals(ALIVE);
     }

     boolean cellAliveAt(Parse leftTop, int x, int y) {
         Parse cell = leftTop.at(x, y);
         if (x == 0 && y == 0) {
             return isAlive(cell);
         }
         return cell != leftTop && isAlive(cell);
     }

     int neighborCount(Parse leftTop) {
         int result = 0;
         for(int x = 0; x <= 2; x++) {
             for (int y = 0; y <= 2; y++) {
                 if (x == 1 && y == 1)
                     continue;
                 if (cellAliveAt(leftTop, x, y))
                     result++;
             }
         }
         return result;
     }

     void reset() {
         birthList = new ArrayList();
         killList = new ArrayList();
     }

     public void doTable(Parse table) {
         reset();
         doRows(table.parts.more);
         updateCells();
     }

     void updateCells() {
         markCells(birthList, ALIVE);
         markCells(killList, DEAD);
     }

     void markCells(List cellList, String mark) {
         for (Iterator it = cellList.iterator(); it.hasNext(); ) {
             Parse cell = (Parse)it.next();
             cell.body = mark;
         }
     }

     public void doCell(Parse leftTop, int columnNumber) {
         if (neighborCount(leftTop) == 3) {
             markForAwaken(leftTop.at(1, 1));
         }
         else if(neighborCount(leftTop) != 2) {
             markForDeath(leftTop.at(1, 1));
         }
     }

     void markForAwaken(Parse cell) {
         birthList.add(cell);
     }

     void markForDeath(Parse cell) {
         killList.add(cell);
     }
}

Disclaimer: this program has never been run or tested.

Michael Feathers
www.objectmentor.com

#417 From: Robert Martin UncleBob <UncleBob@...>
Date: Wed Jul 2, 2003 4:39 pm
Subject: RE: webapp testing
rmartinoma
Send Email Send Email
 
Marco

I was talking about the *user* interface.  Testing an application through
the GUI is downright evil.

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15
565 Lakeview Pkwy   | Fax: (847) 573-1658
Suite 135           |
Vernon Hills, IL,   | www.objectmentor.com
60061               |
-----------------------------------------------



> -----Original Message-----
> From: Marco Dorantes Martinez [mailto:mdmartin@...]
> Sent: Monday, June 30, 2003 1:48 PM
> To: fitnesse@yahoogroups.com
> Subject: RE: [fitnesse] webapp testing
>
>
> Hello Robert,
>
> Could you please elaborate about this?
>
> When using mock objects, usually there are interfaces
> involved; perhaps
> you are talking about the object under test and his potential declared
> interfaces, that is, test the object through its class, not its
> interface?
>
> Most likely we are talking about different things
>
> Thanks in advance,
>
> -----Original Message-----
> From: Robert Martin UncleBob [mailto:UncleBob@...]
> Sent: Monday, June 30, 2003 1:11 PM
> To: 'fitnesse@yahoogroups.com'
> Subject: RE: [fitnesse] webapp testing
>
> And as we all know, testing through the interface leads to horrible
> woes,
> moaning, wailing, and gnashing of teeth.  Do as little testing through
> the
> interface as possible!
>
> -----------------------------------------------
> Robert C. Martin    |
> President & Founder |
> Object Mentor Inc.  | unclebob @ objectmentor dot com
> PO Box 5757         | Tel: (800) 338-6716 x15
> 565 Lakeview Pkwy   | Fax: (847) 573-1658
> Suite 135           |
> Vernon Hills, IL,   | www.objectmentor.com
> 60061               |
> -----------------------------------------------
>
>
>
> > -----Original Message-----
> > From: jbrekke@... [mailto:jbrekke@...]
> > Sent: Friday, June 27, 2003 10:33 AM
> > To: fitnesse@yahoogroups.com
> > Subject: Re: [fitnesse] webapp testing
> >
> >
> > Micah Martin <micah@...> writes:
> >
> > > Anything is possible in FitNesse as long as you have the
> > right Fixture ;).
> > >
> > > It is possible to test your servlet using HtmlFixture;
> > you'll need to
> > > specifie URLs with the query string representing the data
> > you fill in.
> > >
> > > However there is a better solution on the way.
> > > Jim Long started work on an awesome Fixture that I've been
> > working with
> > > lately.  A typical table looks like this:
> > >
> > > |goto_link|http://www.somesite.com/somePage.html|
> > > |enter_field|name|Micah|
> > > |enter_field|email|micah@...|
> > > |click_button|Submit|
> > > |page_contains|Form results|
> > >
> > > As you can see it allows you to write tests as though you
> > were using the
> > > browser.  In addition it actually loads IE and communicates
> > though COM.
> > > That means you can watch the tests walk through all the
> > steps.  As soon as
> > > we get the time we'll encorporate this into WATT.
> >
> > We do the exact same thing using jWebFit ( which uses
> > jWebUnit ) and fitnesse.  Works great, except we are going
> > through the interface to test everything.
> >
> > --
> >
> =====================================================================
> > Jeffrey D. Brekke
> jbrekke@...
> > Wisconsin,  USA
> brekke@...
> >
> ekkerbj@...
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-->
> > Looking for the latest Free IT White Papers?
> > Visit SearchMobileComputing.com to access over 500 white papers.
> > Get instant access at SearchMobileComputing.com Today
> > http://us.click.yahoo.com/ZyjvfD/PLNGAA/uitMAA/03wwlB/TM
> > --------------------------------------------------------------
> > -------~->
> >
> > To unsubscribe from this group, send an email to:
> > fitnesse-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
> To unsubscribe from this group, send an email to:
> fitnesse-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Looking for the latest Free IT White Papers?
> Visit SearchSecurity.com to access over 500 white papers.
> Get instant access at SearchSecurity.com Today
> http://us.click.yahoo.com/ayjvfD/QLNGAA/uitMAA/03wwlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> fitnesse-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

#418 From: Robert Martin UncleBob <UncleBob@...>
Date: Wed Jul 2, 2003 4:41 pm
Subject: RE: webapp testing
rmartinoma
Send Email Send Email
 
> -----Original Message-----
> From: John Goodsen [mailto:jgoodsen@...]

> You can give me lashes for testing from the interface next week, Bob!
> :-)


Goody goody!  I'll get some of my special "toys" ready.

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15
565 Lakeview Pkwy   | Fax: (847) 573-1658
Suite 135           |
Vernon Hills, IL,   | www.objectmentor.com
60061               |
-----------------------------------------------

#419 From: "Phlip" <plumlee@...>
Date: Wed Jul 2, 2003 4:49 pm
Subject: Re: webapp testing
phlip_cpp
Send Email Send Email
 
Robert Martin UncleBob wrote:

> Testing an application through
> the GUI is downright evil.

Testing more than one layer away from the testee is ... suspect.

--
Phlip

#420 From: John Goodsen <jgoodsen@...>
Date: Wed Jul 2, 2003 6:22 pm
Subject: Re: webapp testing
jgoodsen
Send Email Send Email
 
On Wed, 2003-07-02 at 09:49, Phlip wrote:
> Robert Martin UncleBob wrote:
>
> > Testing an application through
> > the GUI is downright evil.
>
> Testing more than one layer away from the testee is ... suspect.

Yeah, I agree.  I think Bob is saying "evil" because it *can* be
hard to maintain.  Some of the FIT fixtures I've been working on
will reduce that maintenance issue drastically.

... but my preference is for an automated test to test as high
up the food chain as possible.  We want to simulate the user
actually running the application.  Designing the acceptance
tests to run at the GUI level tests as much of the application
as we possibly can.  That's why I prefer it. .... but there
is definitely a cost/benefit trade-off if it is too hard to
build and maintain such tests.

--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Extreme Java Development & Consulting
http://www.radsoft.com          Rapid Software Delivery Specialists

#421 From: "Phlip" <plumlee@...>
Date: Wed Jul 2, 2003 6:30 pm
Subject: Re: webapp testing
phlip_cpp
Send Email Send Email
 
> ... but my preference is for an automated test to test as high
> up the food chain as possible.  We want to simulate the user
> actually running the application.  Designing the acceptance
> tests to run at the GUI level tests as much of the application
> as we possibly can.  That's why I prefer it. .... but there
> is definitely a cost/benefit trade-off if it is too hard to
> build and maintain such tests.

Also it looks just so cute when you see your app pop up and drive itself,
very fast, for a while!

--
   Phlip
              http://www.c2.com/cgi/wiki?DevNull
   --  All sensors report Patti having a very good time  --

#422 From: Robert Martin UncleBob <UncleBob@...>
Date: Wed Jul 2, 2003 7:38 pm
Subject: RE: Possible bug?
rmartinoma
Send Email Send Email
 
David,
 
Good catch.  That was definitely a bug.  The problem was that the italic widget would not recognize a single character.  ''xx'' worked fine but ''x'' failed.  You don't want to know why this was, except to say that we used an unsuccessful strategy to differentiate '''x''' from ''x''.
 
Bob.
-----Original Message-----
From: David Hooker [mailto:dhooker@...]
Sent: Tuesday, July 01, 2003 5:17 PM
To: fitnesse@yahoogroups.com
Subject: [fitnesse] Possible bug?

In my page, I have the following markup:
 
All files received within the ''do...while'' loop will be stored using the names "reply'''-x'''", where ''x'' is a number corresponding to which pass through the loop the fixture is taking. 
 
If I put two single quotes around the letter x (in red above), it starts an italic section, but the closing two single quotes do not stop the italics, and the entire rest of my page is itallics.  Bold markup does not seem to have this problem.

#423 From: Robert Martin UncleBob <UncleBob@...>
Date: Wed Jul 2, 2003 8:03 pm
Subject: RE: Sorry, I just wanted to be the first one to do thi s..
rmartinoma
Send Email Send Email
 
Nice try, but no dice.

I tried it out and fiddled with it for awhile.  Then I decided that I really
did have work to do, so I abandoned it.

I think you'd be better off figuring out the size of the table, and then
indexing the cells from the topleft of the table, rather than overriding
doCells.

Bob.

#424 From: Robert Martin UncleBob <UncleBob@...>
Date: Wed Jul 2, 2003 8:07 pm
Subject: RE: webapp testing
rmartinoma
Send Email Send Email
 
> -----Original Message-----
> From: John Goodsen [mailto:jgoodsen@...]

> ... but my preference is for an automated test to test as high
> up the food chain as possible.  We want to simulate the user
> actually running the application.  Designing the acceptance
> tests to run at the GUI level tests as much of the application
> as we possibly can.  That's why I prefer it. .... but there
> is definitely a cost/benefit trade-off if it is too hard to
> build and maintain such tests.

As you say, the advantage to testing through the GUI is that you get to test
all the way through the system.  The disadvantage is that you create
hundreds, perhaps thousands, of tests that use the GUI.  This makes the GUI
nearly impossible to change -- and the GUI is the thing that is most likely
to change.

I have a client who has 10,000 tests that go through the GUI.  They've
forgotten what all the tests do, but they know they have to run them all.
The GUI is an old style DOS character format GUI.  They can't change it!

The solution, IMHO, is to create an API that is very close to the GUI, but
just below it.  And to run almost all your tests through it.  The only tests
to run through the GUI are tests that actually test the GUI.

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15
565 Lakeview Pkwy   | Fax: (847) 573-1658
Suite 135           |
Vernon Hills, IL,   | www.objectmentor.com
60061               |
-----------------------------------------------

#425 From: John Goodsen <jgoodsen@...>
Date: Wed Jul 2, 2003 11:37 pm
Subject: RE: webapp testing
jgoodsen
Send Email Send Email
 
do you find that a customer can easily understand the underlying API
enough to write FIT tests against it?  I am thinking that the closer
the specification language is to the actual user interface, the easier
a customer will be able to write tests... but it is theory.  I have
not used FIT on a project yet.

John

On Wed, 2003-07-02 at 13:07, Robert Martin UncleBob wrote:
> > -----Original Message-----
> > From: John Goodsen [mailto:jgoodsen@...]
>
> > ... but my preference is for an automated test to test as high
> > up the food chain as possible.  We want to simulate the user
> > actually running the application.  Designing the acceptance
> > tests to run at the GUI level tests as much of the application
> > as we possibly can.  That's why I prefer it. .... but there
> > is definitely a cost/benefit trade-off if it is too hard to
> > build and maintain such tests.
>
> As you say, the advantage to testing through the GUI is that you get to test
> all the way through the system.  The disadvantage is that you create
> hundreds, perhaps thousands, of tests that use the GUI.  This makes the GUI
> nearly impossible to change -- and the GUI is the thing that is most likely
> to change.
>
> I have a client who has 10,000 tests that go through the GUI.  They've
> forgotten what all the tests do, but they know they have to run them all.
> The GUI is an old style DOS character format GUI.  They can't change it!
>
> The solution, IMHO, is to create an API that is very close to the GUI, but
> just below it.  And to run almost all your tests through it.  The only tests
> to run through the GUI are tests that actually test the GUI.
>
> -----------------------------------------------
> Robert C. Martin    |
> President & Founder |
> Object Mentor Inc.  | unclebob @ objectmentor dot com
> PO Box 5757         | Tel: (800) 338-6716 x15
> 565 Lakeview Pkwy   | Fax: (847) 573-1658
> Suite 135           |
> Vernon Hills, IL,   | www.objectmentor.com
> 60061               |
> -----------------------------------------------
>
>
>
> To unsubscribe from this group, send an email to:
> fitnesse-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Extreme Java Development & Consulting
http://www.radsoft.com          Rapid Software Delivery Specialists

#426 From: "Phlip" <plumlee@...>
Date: Thu Jul 3, 2003 1:19 pm
Subject: Re: webapp testing
phlip_cpp
Send Email Send Email
 
John Goodsen wrote:


> do you find that a customer can easily understand the underlying API
> enough to write FIT tests against it?  I am thinking that the closer
> the specification language is to the actual user interface, the easier
> a customer will be able to write tests... but it is theory.  I have
> not used FIT on a project yet.

Suppose a project accepted a grid full of numbers, and output weighted
contour plots on those numbers. A very graphical scenario.

Now suppose the user interface let you click on those lines and drag them
around (if, for example, they don't support your hypothesis).

Most of the GUI is logic to support all the dragging. Of course it has
tests, but the customer does not want to test that draggers drag. They want
to test certain grids of numbers create certain elevations. And they may
want to test that changes to the input parameters (the end-result of
dragging) change those elevations within tolerances.

The main body of tests will be grids of numbers. The onsite customer always
wants to bypass most GUI, and wants to automate the equivalent of the
program's bulk import system.

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

#427 From: William Pietri <william@...>
Date: Thu Jul 3, 2003 4:54 pm
Subject: RE: webapp testing
william_pietri
Send Email Send Email
 
On Wed, 2003-07-02 at 13:07, Robert Martin UncleBob wrote:

> As you say, the advantage to testing through the GUI is that you get to test
> all the way through the system.  The disadvantage is that you create
> hundreds, perhaps thousands, of tests that use the GUI.  This makes the GUI
> nearly impossible to change -- and the GUI is the thing that is most likely
> to change.
>
> I have a client who has 10,000 tests that go through the GUI.  They've
> forgotten what all the tests do, but they know they have to run them all.
> The GUI is an old style DOS character format GUI.  They can't change it!
>
> The solution, IMHO, is to create an API that is very close to the GUI, but
> just below it.  And to run almost all your tests through it.  The only tests
> to run through the GUI are tests that actually test the GUI.

Or you could create an API that is very close to the GUI, but just above
it. For my acceptance tests for http://www.longbets.org/, everything
goes through a class called LongBetsRobot. It has methods like
robot.logInAsAdministrator(), robot.placeBet(title, details, wager), and
so on. Beneath that, I ended up with objects representing lower-level
concepts, like pages and page sequences.

Could it be that the 10,000 tests are not built with the same care
production code is? In particular, is it possible that they have lots of
duplication? Or that the test code doesn't express the intentions of the
programmer?


This is not to say that doing all tests via the GUI is a good idea, of
course. GUIs are slow. It's also hard to test unusual cases (like
internal error handling) without exposing far too much. But with solid
unit testing coverage, relatively simple end-to-end tests provided a
level of bug reduction and confidence that I wasn't able to get any
other way.

William

#428 From: Robert Martin UncleBob <UncleBob@...>
Date: Thu Jul 3, 2003 7:23 pm
Subject: RE: webapp testing
rmartinoma
Send Email Send Email
 
> -----Original Message-----
> From: William Pietri [mailto:william@...]
> Sent: Thursday, July 03, 2003 11:55 AM
> To: fitnesse@yahoogroups.com
> Subject: RE: [fitnesse] webapp testing
>
>
> On Wed, 2003-07-02 at 13:07, Robert Martin UncleBob wrote:
>
> > As you say, the advantage to testing through the GUI is
> that you get to test
> > all the way through the system.  The disadvantage is that you create
> > hundreds, perhaps thousands, of tests that use the GUI.
> This makes the GUI
> > nearly impossible to change -- and the GUI is the thing
> that is most likely
> > to change.
> >
> > I have a client who has 10,000 tests that go through the
> GUI.  They've
> > forgotten what all the tests do, but they know they have to
> run them all.
> > The GUI is an old style DOS character format GUI.  They
> can't change it!
> >
> > The solution, IMHO, is to create an API that is very close
> to the GUI, but
> > just below it.  And to run almost all your tests through
> it.  The only tests
> > to run through the GUI are tests that actually test the GUI.
>
> Or you could create an API that is very close to the GUI, but
> just above
> it. For my acceptance tests for http://www.longbets.org/, everything
> goes through a class called LongBetsRobot. It has methods like
> robot.logInAsAdministrator(), robot.placeBet(title, details,
> wager), and
> so on. Beneath that, I ended up with objects representing lower-level
> concepts, like pages and page sequences.

Interesting idea.  So when the GUI changes, all you have to change is the
Robot.  The benefit is that your tests test the whole system.  The
disadvantages probably relate to preformance of the tests, migrating the
robot, and the possibility that the application is too coupled to the GUI.
>
> Could it be that the 10,000 tests are not built with the same care
> production code is? In particular, is it possible that they
> have lots of
> duplication? Or that the test code doesn't express the
> intentions of the
> programmer?

This application grew over the last 15 years.  The tests were written in
terms of <menu number>, <item number>, <field number>, etc.  Thus they'd say
"invoke item 7 of menu 6 and then load "xyzzy" into field 3 and push button
1."  Nobody can read these tests anymore.  Nobody know what the intention of
the tests is.  They've completely lost control of the tests; and they can't
make even the simplest changes to the GUI.
>

#429 From: William Pietri <william@...>
Date: Thu Jul 3, 2003 8:36 pm
Subject: RE: webapp testing
william_pietri
Send Email Send Email
 
On Thu, 2003-07-03 at 12:23, Robert Martin UncleBob wrote:
> >
> > Or you could create an API that is very close to the GUI, but
> > just above it. For my acceptance tests for http://www.longbets.org/,
> > everything goes through a class called LongBetsRobot. It has methods like
> > robot.logInAsAdministrator(), robot.placeBet(title, details, wager), and
> > so on. Beneath that, I ended up with objects representing lower-level
> > concepts, like pages and page sequences.
>
> Interesting idea.  So when the GUI changes, all you have to change is the
> Robot.  The benefit is that your tests test the whole system.

Yes.

> The
> disadvantages probably relate to preformance of the tests, migrating the
> robot

The performance is indeed not so great; some of my acceptance tests went
below the UI layer for just this reason. One interesting way to mitigate
this is to make it so that the Robot is abstract, and that there are two
concrete subclasses. One deals with the full HTTP/HTML approach; the
other uses a mock servlet container to run all of the code but the HTML.
Then you can run all the same tests either way.

Modifying the robot is indeed required work when the UI changes,
although if you are following good XP practices the changes should be no
worse than proportional to changes in the underlying code.

On the other hand, there's some benefit to being forced to look at the
app from the outside like that; it helps point out duplication or object
model issues that may not be obvious under the hood.


> the possibility that the application is too coupled to the GUI.

Hmmm... Too coupled for what?

I ask because with a couple of recent web apps, I have some of that
coupling, at least in that the StrutsAction classes contain business
logic. I had the urge to pull those things out into something like
separate BusinessCommand classes, but the times I did it seemed to make
the code murkier rather than more clear. So I said "YAGNI" and left
things alone.

I'm waiting until requirements force me to pull the business logic
entirely into its own layer, but that hasn't happened quite yet. The
coupling would be bad were I planning to, say, make a Swing interface or
separate batch jobs, but for now separating the layers seemed like BDUF
to me.

So I guess I'm saying that having tests force me into additional work
may not be a plus.

> > Could it be that the 10,000 tests are not built with the same care
> > production code is? In particular, is it possible that they
> > have lots of
> > duplication? Or that the test code doesn't express the
> > intentions of the
> > programmer?
>
> This application grew over the last 15 years.  The tests were written in
> terms of <menu number>, <item number>, <field number>, etc.  Thus they'd say
> "invoke item 7 of menu 6 and then load "xyzzy" into field 3 and push button
> 1."  Nobody can read these tests anymore.  Nobody know what the intention of
> the tests is.  They've completely lost control of the tests; and they can't
> make even the simplest changes to the GUI.

Heh. I would blame this particular case on bad coding then, rather than
GUI testing. It sounds like refactoring the tests should proceed in
parallel with refactoring the legacy code.

Not to say that it isn't a common mistake even on XP teams. I certainly
have made the mistake of thinking that my test code didn't need to be as
pretty as my regular code. The resultant pain has taught me otherwise.
:-)

William

#430 From: Robert Martin UncleBob <UncleBob@...>
Date: Thu Jul 3, 2003 8:52 pm
Subject: RE: webapp testing
rmartinoma
Send Email Send Email
 
> -----Original Message-----
> From: John Goodsen [mailto:jgoodsen@...]
>
> do you find that a customer can easily understand the underlying API
> enough to write FIT tests against it?

Yes and no.  The customer's don't really understand the underlying API.
Rather the customers write tables the way they want them to look.  The
developers write fixtures that translate those tables into the necessary API
calls.

> I am thinking that the closer
> the specification language is to the actual user interface, the easier
> a customer will be able to write tests... but it is theory.

I don't know.  I've seen FitNesse tables that look a *lot* like the UI, and
I've seen some that bear no resemblance to the UI.  When an application has
deep rules, the UI seems to become more of an impediment than a good testing
interface.

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15
565 Lakeview Pkwy   | Fax: (847) 573-1658
Suite 135           |
Vernon Hills, IL,   | www.objectmentor.com
60061               |
-----------------------------------------------

#431 From: Robert Martin UncleBob <UncleBob@...>
Date: Thu Jul 3, 2003 9:06 pm
Subject: RE: webapp testing
rmartinoma
Send Email Send Email
 
> -----Original Message-----
> From: William Pietri [mailto:william@...]

> The performance is indeed not so great; some of my acceptance
> tests went
> below the UI layer for just this reason. One interesting way
> to mitigate
> this is to make it so that the Robot is abstract, and that
> there are two
> concrete subclasses. One deals with the full HTTP/HTML approach; the
> other uses a mock servlet container to run all of the code
> but the HTML.
> Then you can run all the same tests either way.

Very cool!  That way you can test under the UI or over the UI as you please!
>
> On the other hand, there's some benefit to being forced to look at the
> app from the outside like that; it helps point out
> duplication or object
> model issues that may not be obvious under the hood.

Hmmm.   That's interesting.  Can you provide an example?

> > the possibility that the application is too coupled to the GUI.
>
> Hmmm... Too coupled for what?

When the application is coupled to the GUI, then GUI changes cause changes
to code that contains business rules.  In the best case, this just means
that business code runs the risk of getting broken due to cosmetic changes.
In the worse case, the business rules may depend so heavily on the way the
GUI works that making the cosmetic change is to hard and risky.

> I ask because with a couple of recent web apps, I have some of that
> coupling, at least in that the StrutsAction classes contain business
> logic. I had the urge to pull those things out into something like
> separate BusinessCommand classes, but the times I did it
> seemed to make
> the code murkier rather than more clear. So I said "YAGNI" and left
> things alone.

I find that writing unit tests that isolate the business rules from the GUI
force me to build the API anyway.  One of my rules for unit tests is that
each unit be tested independently of each other unit.  I also write unit
tests that test clusters of units, but I try to make sure that there are
tests that test each unit independently.  This forces me to separate GUI
from Business Rules, and Business Rules from Databases, etc.

> I'm waiting until requirements force me to pull the business logic
> entirely into its own layer, but that hasn't happened quite yet. The
> coupling would be bad were I planning to, say, make a Swing
> interface or
> separate batch jobs, but for now separating the layers seemed
> like BDUF
> to me.

Reasonable decoupling does not mean you are practicing BDUF, or even
violating YAGNI.  Decoupling is like refactoring -- indeed it is *part* of
refactoring.  It's something you do because it improves the quality of the
code.  It's like changing the name of a method to be more expressive, or
eliminating a stretch of duplicate code.  It's part of keeping the code
clean.

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15
565 Lakeview Pkwy   | Fax: (847) 573-1658
Suite 135           |
Vernon Hills, IL,   | www.objectmentor.com
60061               |
-----------------------------------------------

#432 From: Daši Ingólfsson <dadi@...>
Date: Fri Jul 4, 2003 1:35 pm
Subject: Classpath problem
comspy66
Send Email Send Email
 

Hi,

I needed to do a little bit of refactoring of our tests and so proceeded to split them into more suites. However, I run into a pretty obvious classpath problem when I run the new suites. The error in the ErrorLog is:

java -cp defaultPath fitnesse.FitFilter
----
java.lang.NoClassDefFoundError: fitnesse/FitFilter
Exception in thread "main"

When I run the tests in these suites individually they seem to find the classes without a problem.

What gives?

ps. You can take a look at one of these suites if you like at

http://193.4.185.35/FitNesse.LanasjodurIslenskraNamsmanna.ReikniForrit.AllTests.SuiteFramfaerslaTests ,

but please don“t run the whole top-level suite at

http://193.4.185.35/FitNesse.LanasjodurIslenskraNamsmanna.ReikniForrit.AllTests since that puts the system under a lot of stress ;-)

Regards,
Dadi.


#433 From: Robert Martin UncleBob <UncleBob@...>
Date: Fri Jul 4, 2003 10:41 pm
Subject: RE: Classpath problem
rmartinoma
Send Email Send Email
 
Dear Daši
 
The problem is that your test pages are not sub pages of your suite page.  I changed your suite page and created a subpage for one of the tests.  Now the suite runs one test, but not the others.  You'll need to add sub pages for the other tests and then move the contents of those tests into the sub pages.
 

-----------------------------------------------
Robert C. Martin    |
President & Founder |
Object Mentor Inc.  | unclebob @ objectmentor dot com
PO Box 5757         | Tel: (800) 338-6716 x15     
565 Lakeview Pkwy   | Fax: (847) 573-1658  
Suite 135           |                          
Vernon Hills, IL,   | www.objectmentor.com    
60061               |                         
-----------------------------------------------

-----Original Message-----
From: Daši Ingólfsson [mailto:dadi@...]
Sent: Friday, July 04, 2003 8:35 AM
To: fitnesse@yahoogroups.com
Subject: [fitnesse] Classpath problem

Hi,

I needed to do a little bit of refactoring of our tests and so proceeded to split them into more suites. However, I run into a pretty obvious classpath problem when I run the new suites. The error in the ErrorLog is:

java -cp defaultPath fitnesse.FitFilter
----
java.lang.NoClassDefFoundError: fitnesse/FitFilter
Exception in thread "main"

When I run the tests in these suites individually they seem to find the classes without a problem.

What gives?

ps. You can take a look at one of these suites if you like at

http://193.4.185.35/FitNesse.LanasjodurIslenskraNamsmanna.ReikniForrit.AllTests.SuiteFramfaerslaTests ,

but please don“t run the whole top-level suite at

http://193.4.185.35/FitNesse.LanasjodurIslenskraNamsmanna.ReikniForrit.AllTests since that puts the system under a lot of stress ;-)

Regards,
Dadi.



To unsubscribe from this group, send an email to:
fitnesse-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

#434 From: Robert Martin UncleBob <UncleBob@...>
Date: Sun Jul 6, 2003 4:44 pm
Subject: Uncle Bob at ADC.
rmartinoma
Send Email Send Email
 
Steve Berczuk captured this one.

#435 From: "Phlip" <plumlee@...>
Date: Sun Jul 6, 2003 11:36 pm
Subject: POST form-data to a Web site?
phlip_cpp
Send Email Send Email
 
FitNesse:

How would one write a page that assembles a table of data into an HTTP POST
message, sends it to a server, and displays the response?

I figured this would be a common kind of test, but my feeb search attempts
did not find it in the FitNesse web sites.

--
   Phlip

#436 From: William Pietri <william@...>
Date: Mon Jul 7, 2003 5:42 am
Subject: RE: webapp testing
william_pietri
Send Email Send Email
 
On Thu, 2003-07-03 at 14:06, Robert Martin UncleBob wrote:
>
> > On the other hand, there's some benefit to being forced to look at the
> > app from the outside like that; it helps point out
> > duplication or object
> > model issues that may not be obvious under the hood.
>
> Hmmm.   That's interesting.  Can you provide an example?

Sure thing.

In a web context, because everything boils down to single GET or POST
request against URLs, it's easy to view things as a set of discreet
actions. As you add features, it's easy to get use to adding a lot of
little command objects. But doing testing from the outside, it becomes
more clear that there are relationships between the discrete actions.
(E.g., that they go in sequence, like the 1-2-3-4 of a wizard.) That can
suggest a new object (perhaps ActionSequence or Wizard) to represent the
previously unspoken notion in the user's head.


Another example: because of the traditional division of labor
(HTML/graphics people vs coders), it's easy for the programmers to think
of things only from the under-the-hood perspective. End-to-end testing
also it easier to see that common elements (like a menu, tabs, or a
login box on every page) should be represented in a common fashion not
just in the testing robot, but under the hood as well.


> > I'm waiting until requirements force me to pull the business logic
> > entirely into its own layer, but that hasn't happened quite yet. The
> > coupling would be bad were I planning to, say, make a Swing
> > interface or separate batch jobs, but for now separating the layers
> > seemed  like BDUF to me.
>
> Reasonable decoupling does not mean you are practicing BDUF, or even
> violating YAGNI.  Decoupling is like refactoring -- indeed it is *part* of
> refactoring.  It's something you do because it improves the quality of the
> code.  It's like changing the name of a method to be more expressive, or
> eliminating a stretch of duplicate code.  It's part of keeping the code
> clean.

Hmmm... Let me give you a concrete example from a recent web project.
Imagine a site for listing public events. An Event object might have
fields like date, time, location, title, and details.

The way things ended up, the web side had a few Action objects, things
like AddEvent, EditEvent, DeleteEvent, ShowSingleEvent, and
ShowEventList. Now those Action objects only had a few lines of code
each, but they contained both web-related code and business-related
code.

Were I being strict about decoupling my layers, or had I the need to add
an event from more than one action, I would have pulled the logic out
and put it somewhere else, like an EventFactory or some sort of
business-layer Command object. but as it was, we saw no need; the
various event-related action objects were clear and easy to test.
Indeed, when I tried it, the additional entities seemed to confuse the
picture.

The same goes for view-layer stuff. For some objects, where display
representations are pretty different than the raw objects, we created
special View objects. But there wasn't a need for an EventView; it was
simpler to just let the HTML guys use an Event rather than introducing a
new entity that had a bunch of code for copying or proxying every Event
field.

Now I don't doubt that at some point we'll want to pull the layers apart
cleanly. Indeed, I think that we've begun that process at the points
where the system is most complex, as the layering helps make things
clearer. But it feels to me something like peeling a banana: if you wait
until ripe, they pop open with just a little pressure in the right
spots.

William


--
brains for sale: http://scissor.com/

#437 From: John Goodsen <jgoodsen@...>
Date: Mon Jul 7, 2003 6:20 pm
Subject: RE: webapp testing
jgoodsen
Send Email Send Email
 
See also: http://strutstestcase.sourceforge.net/
You can run the same "unit" tests against mocks or Cactus,
(with a little design work to make it happen)

John


On Sun, 2003-07-06 at 22:42, William Pietri wrote:
> On Thu, 2003-07-03 at 14:06, Robert Martin UncleBob wrote:
> >
> > > On the other hand, there's some benefit to being forced to look at the
> > > app from the outside like that; it helps point out
> > > duplication or object
> > > model issues that may not be obvious under the hood.
> >
> > Hmmm.   That's interesting.  Can you provide an example?
>
> Sure thing.
>
> In a web context, because everything boils down to single GET or POST
> request against URLs, it's easy to view things as a set of discreet
> actions. As you add features, it's easy to get use to adding a lot of
> little command objects. But doing testing from the outside, it becomes
> more clear that there are relationships between the discrete actions.
> (E.g., that they go in sequence, like the 1-2-3-4 of a wizard.) That can
> suggest a new object (perhaps ActionSequence or Wizard) to represent the
> previously unspoken notion in the user's head.
>
>
> Another example: because of the traditional division of labor
> (HTML/graphics people vs coders), it's easy for the programmers to think
> of things only from the under-the-hood perspective. End-to-end testing
> also it easier to see that common elements (like a menu, tabs, or a
> login box on every page) should be represented in a common fashion not
> just in the testing robot, but under the hood as well.
>
>
> > > I'm waiting until requirements force me to pull the business logic
> > > entirely into its own layer, but that hasn't happened quite yet. The
> > > coupling would be bad were I planning to, say, make a Swing
> > > interface or separate batch jobs, but for now separating the layers
> > > seemed  like BDUF to me.
> >
> > Reasonable decoupling does not mean you are practicing BDUF, or even
> > violating YAGNI.  Decoupling is like refactoring -- indeed it is *part* of
> > refactoring.  It's something you do because it improves the quality of the
> > code.  It's like changing the name of a method to be more expressive, or
> > eliminating a stretch of duplicate code.  It's part of keeping the code
> > clean.
>
> Hmmm... Let me give you a concrete example from a recent web project.
> Imagine a site for listing public events. An Event object might have
> fields like date, time, location, title, and details.
>
> The way things ended up, the web side had a few Action objects, things
> like AddEvent, EditEvent, DeleteEvent, ShowSingleEvent, and
> ShowEventList. Now those Action objects only had a few lines of code
> each, but they contained both web-related code and business-related
> code.
>
> Were I being strict about decoupling my layers, or had I the need to add
> an event from more than one action, I would have pulled the logic out
> and put it somewhere else, like an EventFactory or some sort of
> business-layer Command object. but as it was, we saw no need; the
> various event-related action objects were clear and easy to test.
> Indeed, when I tried it, the additional entities seemed to confuse the
> picture.
>
> The same goes for view-layer stuff. For some objects, where display
> representations are pretty different than the raw objects, we created
> special View objects. But there wasn't a need for an EventView; it was
> simpler to just let the HTML guys use an Event rather than introducing a
> new entity that had a bunch of code for copying or proxying every Event
> field.
>
> Now I don't doubt that at some point we'll want to pull the layers apart
> cleanly. Indeed, I think that we've begun that process at the points
> where the system is most complex, as the layering helps make things
> clearer. But it feels to me something like peeling a banana: if you wait
> until ripe, they pop open with just a little pressure in the right
> spots.
>
> William
--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Extreme Java Development & Consulting
http://www.radsoft.com          Rapid Software Delivery Specialists

#438 From: Brad Clarke <prow1er@...>
Date: Mon Jul 7, 2003 6:52 pm
Subject: Patch: Link to FrontPage from logo
prow1er
Send Email Send Email
 
I kept finding myself wanting to go back to the front page. I'm sure
there's a nicer way to do this but I didn't want to rewrite the whole class :)


diff C:\temp\src\fitnesse\responders\html/HtmlBuilder.java ./HtmlBuilder.java
52c52
< 	 output.println("   <img src=\"/files/images/FitNesseLogoIcon.jpg\">");
---
  > 	 output.println("   <a href=\"/FrontPage\"><img
src=\"/files/images/FitNesseLogoIcon.jpg\" border=\"0\"></a>");
diff C:\temp\src\fitnesse\responders\html/HtmlBuilderTest.java
./HtmlBuilderTest.java
71a72,84
  >
  >  public void testLinkedFitnesseImage() throws Exception
  >  {
  > 	 HtmlBuilder myBuilder = new HtmlBuilder()
  > 	 {
  > 		 protected void makeHtmlForPageDisplay(PrintWriter output, String
name) throws Exception
  > 		 {
  > 			 surroundPageWithPrettyTable(output, name, "UselessTitle");
  > 		 }
  > 	 };
  >
  > 	 assertHasRegexp("<a href=\"/FrontPage\">.*</a>",
myBuilder.makeHtml("Name", "#ABCABC"));
  >  }


Brad C

Messages 409 - 438 of 20121   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help