headers
June Clarke | 1 Apr 2004 01:18
Picon
Favicon

ANN: XPSD April meeting tomorrow

The topic for month’s presentation at eXtreme
Programming San Diego will be "Introduction to Test
Driven Development".  The meeting will take place
tomorrow, April 1st, at Alaris Medical (see below for
directions) from 6-8PM. Phlip; a local TDD guru will
be giving the presentation. 

Test Driven Development (TDD) is an evolutionary
approach to software development which involves first
writing a test that fails before writing any new
functional code. This lifecycle has been shown to
allow simple design principles to emerge into advanced
and flexible object models. TDD is a discipline which
should be investigated and used by any serious
software engineer who wishes to avoid buggy and
tightly coupled code. 

Phlip Plumlee has many years of experience in TDD and
is currently writing a book on using TDD to create
advanced Graphical User Interfaces under the Kent Beck
signature series.

This is an open meeting; invite anyone interested in
XP or TDD. Please RSVP by replying to this email
(joonspoon <at> yahoo.com) so that an appropriately sized
room can be scheduled. 

We will be meeting at Alaris Medical, 10221 Wateridge
Circle. For directions, see
http://xpsd.org/XPSDAlarisDirections
(Continue reading)

Permalink | Reply | 0 comments |
headers
June Clarke | 2 Apr 2004 00:28
Picon
Favicon

[TFUI] ANN: XPSD April postponed

I am sorry to announce that our meeting place has
become unavailable so we have had to postpone the TDD
presentation until next Wednesday, April 7th. Please
RSVP to joonspoon@... if you plan to attend next
week.

June.

--- June Clarke <joonspoon@...> wrote:
> Date: Wed, 31 Mar 2004 15:18:24 -0800 (PST)
> From: June Clarke <joonspoon@...>
> Subject: ANN: XPSD April meeting tomorrow
> To: xpsandiego@...
> 
> The topic for month’s presentation at eXtreme
> Programming San Diego will be "Introduction to Test
> Driven Development".  The meeting will take place
> tomorrow, April 1st, at Alaris Medical (see below
> for
> directions) from 6-8PM. Phlip; a local TDD guru will
> be giving the presentation. 
> 
> Test Driven Development (TDD) is an evolutionary
> approach to software development which involves
> first
> writing a test that fails before writing any new
> functional code. This lifecycle has been shown to
> allow simple design principles to emerge into
> advanced
> and flexible object models. TDD is a discipline
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 21 Apr 2004 04:31
Picon
Favicon

[TFUI] HttpUnit Tutorial

http://www.c2.com/cgi/wiki?HttpUnitTutorial

That shows A> Dilbert.gif, without the ads and stuff,
and B> reveal(), which is my "Treat I/O Like a Spigot"
theme.

TDD-ing a Web site is easy, if you configure reveal()
so your images appear in the correct places relative
to the temporary file it browses. Then you read the
page, and write statements before your reveal call
that assert its state, or statements that click on it
and drive it forward.

In some situations one must bounce a server before
seeing the pages online. Reveal accelerates this
feedback.

=====
Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...
(Continue reading)

Permalink | Reply | 0 comments |
headers
maraflux | 21 Apr 2004 05:22

[TFUI] newbie wants to understand TFUI with jemmy

Hi

So I am trying my first "hands on" experience with TFUI using jemmy and the (extended) 
example from Astels's "TDD: A Practical Guide," chapter 10. So what I have now, as far as I 
can see is a GUI that gets built by jemmy! My GUI doesn't exist in that I don't have an app 
to run with it's own GUI. Yet I have tests that build and test a GUI. Seems quite strange to 
me. 

I have yet to work through the other chapters, but I am guessing that I will slowly build the 
same GUI for the app that I use jemmy to build/teardown. This seems like duplication. It 
seems like a lot of extra work and the GUI tests will only be valid if I build the app's GUI in 
the same way that I instruct jemmy to build it in the tests. I know there is the interface and 
the MVC separation by passing the Editor/Controller the "view" and the "model" objects. 
But somehow, this feels contrived as far as testing the GUI... I mean the app technically 
has no GUI yet... do I really need to build/teardown a GUI to test the interface... isn't there 
a way to build the app's actual GUI and test it !!!

Anyway, can someone explain the logic in this approach to me in a manner that will make 
it less foreign and contrived to  me?!

tia

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com.  Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/nhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe, email:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phlip | 21 Apr 2004 21:09
Picon
Favicon

Re: [TFUI] newbie wants to understand TFUI with jemmy

maraflux wrote:

> So I am trying my first "hands on" experience with
> TFUI using jemmy and the (extended) 
> example from Astels's "TDD: A Practical Guide,"
> chapter 10. So what I have now, as far as I 
> can see is a GUI that gets built by jemmy! My GUI
> doesn't exist in that I don't have an app 
> to run with it's own GUI. Yet I have tests that
> build and test a GUI. Seems quite strange to 
> me. 

Can you submit some sample code?

When I use TDD to create a small sample, I seems to be
an app I can use outside the test rig. If anyone wants
an app with a single button.

import java.awt.BorderLayout;

import javax.swing.JFrame;
import javax.swing.JButton;
import javax.swing.JPanel;

import org.netbeans.jemmy.*;
import org.netbeans.jemmy.operators.*;
import org.netbeans.jemmy.operators.JButtonOperator;

public class JemmyScenario implements Scenario {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 26 Apr 2004 07:55
Picon
Favicon

[TFUI] Re: Test first User Interfaces

Will Stott wrote:

> I found this at the bottom of Phlip's message. Does
> anyone have any
> comments about testing GUI?
> 
>
http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

> 
> A technique I've used is to make the User Interface
> very, very simple - like
> just setting the controls' (widgets') Text
properties
> - and putting
> everything else in a testable library.

That fix reveals the latent belief that GUIs are
untestable. They are always worth some small effort.

At one end of the spectrum we have forms and fields.
Testing that <Ctrl+C> does indeed copy is useless,
because the field controls are entirely pre-packaged.

At the other end are custom controls, such as a heat
map that permits mouse- and keystrokes to tune the
colors (or the heat). Fortunately for the "make the
GUI thin and don't test it" side, most of business
simply re-uses their GUI toolkit's control sets. Don't
test getters and setters. But learn how.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 28 Apr 2004 01:51
Picon
Favicon

[TFUI] How to do TFUI

Newsgroupies:

Tests on GUIs should not display any windows. But
programmers writing such tests should display them
early and often.

Here's an example of TFUI in Ruby, using the TkCanvas:

  http://www.rubygarden.org/ruby?SvgCanvas

The source is not on that page, but it uses a function
called maybeMainloop(), which should be called
reveal().

Here's an example using Gtk+, and a function called
reveal():

http://gnomesupport.org/wiki/index.php/TestDrivenDevelopment

(A lot of you are wondering "why not Java"? Because
Ruby can look like Java, with typecasts added and
block closures taken out.)

Here's a near-TFUI sketch in Java, using HttpUnit:

  http://www.c2.com/cgi/wiki?HttpUnitTutorial

It uses reveal() to display today's Dilbert. (I
recently introduced a Romanian programmer to the
existence of Dilbert, leaving me feeling quite
(Continue reading)

Permalink | Reply | 2 comments |
headers
George Dinwiddie | 28 Apr 2004 04:35

Re: [TFUI] How to do TFUI

Phlip wrote:
> Newsgroupies:
> 
> Tests on GUIs should not display any windows. But
> programmers writing such tests should display them
> early and often.

Except that, if you're using Java/Swing, you need to display them or 
they don't work correctly.  Almost correctly, but that just slows you 
down in figuring out what the problem is.

  - George

--

-- 
  ----------------------------------------------------------------------
   When I remember bygone days                         George Dinwiddie
   I think how evening follows morn;            gdinwiddie@...
   So many I loved were not yet dead,           http://www.Alberg30.org
   So many I love were not yet born.
                                             'The Middle' by Ogden Nash
  ----------------------------------------------------------------------

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com.  Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/nhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe, email:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phlip | 28 Apr 2004 15:39
Picon
Favicon

Re: [TFUI] How to do TFUI

George Dinwiddie wrote:

> Except that, if you're using Java/Swing, you need to
> display them or 
> they don't work correctly.  Almost correctly, but
> that just slows you 
> down in figuring out what the problem is.

When using TDD on GUIs, research to approach a
principle "just another library". That means you
minimize side effects for three reasons:

 A> Your colleagues do not despise you

 B> You minimize all reasons for you and them
    not to hit The Test Button

 C> During a test run, however brief, the
    editor remains available and unblocked

On modern hardware, you can get this by commanding
those Swing windows to swing into another monitor, and
to not activate or grab the keyboard focus.

Don't tell me Swing windows require the keyboard focus
to not f*** up under test. Could you submit a 10 line
JUnit sample illustrating the effect?

=====
Phlip
(Continue reading)

Permalink | Reply | 0 comments |

Gmane