[TFUI] Re: User Stories and the UI

[moved to another thread because the OP will need it.]

Ilja Preuss wrote:

> I see. How do you configure wether the window is
> displayed? Do you
> manually comment out a line, pass in a parameter or
> something?

I'm a programmer test-firsting a feature. I'm not in
the integrationist role, or the Quality Control role,
etc.

I want to see my window. The easiest way not to see it
is not call the method that dispatches events. For Tk
this method is mainloop(). For MS Windows it is
GetMessage() and DispatchMessage(). For Visual Basic
it is Show().

    Load frmMyForm
  frmMyForm.Initialize "my data"  '  <-- public method

    myDataBase.setSomeField("")

 frmMyForm.Submit_Click  '  <-- pretend to click on a
                         '        button

    Debug.Assert myDataBase.someField() = "my data"

    ' frmMyForm.Show 1
    Unload frmMyForm

We don't need to test that the Submit button itself is
clickable. Refactoring won't easily change that. That
logic is in the "GUI Toolkit" - we want to test only
our own "GUI Layer".

We assert that the effect of our click went into the
database. Our data appeared in some field. This would
tend to indicate that Submit_Click is the one that
pushed the data into the database.

Next, while programming a GUI we often want to look at
its intermediate state. So I have a commented-out line
that would have called 'Show' in Modal mode. It's
Modal so we block all the other tests until we are
finished looking at the window.

If we see anything wrong we must decide to write a
test, or to just fix it. If it's simple, such as two
fields overlapping, just go to Design Mode and drag
the fields apart. But if you don't know >why< the
fields are overlapping, a test will help investigate.

> That's interesting - can you elaborate on what your
> reusable test
> functions typically test?

Call "test fixture" code re-used by tests. I am aware
others use an overlapping definition for "fixture".
Mine is simply the result of the Extract Method
Refactor on statements born inside a test case.

Call "simulate a user" my line frmMyForm.Submit_Click.
This is a "loose user simulation" because it does not
go thru the same mechanism as bonds Submit_Click with
a button. In VB, there might not be a button called
Submit.

Suppose the above test case wanted to send a low-level
message, for "strict user simulation". If it used
SendMessage(something, BM_CLICK, 0, 0). Statements to
send a low-level message thru VB would be very hairy.
So we should put them inside a common method, to be
re-used whenever we needed a strict user simulation of
a button click event.


=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
     TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

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