Re: [TFUI] The TFUI Principles

On Feb 6, 2005, at 8:53 AM, Phlip wrote:
> GUI Tests on Cocoa don't need to regulate the event queue?
>
> My current career arc won't take me near Apple for a long time.  
> Could you
> help us by showing some GUI tests written for Cocoa?

Sorry I took so long to reply to this.  I've been a bit busy the past  
few months.

In general, human interface tests in Cocoa *don't* need to regulate  
the application's run loop.  You don't need to simulate an event  
queue, you don't need to feed events to controls and see what they  
do.  You can operate at a higher level because Cocoa isn't an object- 
oriented wrapper around an API, it's an object-oriented API.

I'm not going to write example tests, but I will say how you would  
write the tests.

For example, let's say you're building an interface that contains a  
button you want to invoke a method.  You can start out by writing a  
test that verifies you can instantiate the NSWindowController  
subclass that will manage the window.  Then you can test that this  
window controller has the right window nib name; a "nib" is an  
resource file that contains an archived object graph representing an  
interface.  After that, check that asking the window controller for  
its window will give you an NSWindow instance configured appropriately.

At each step tests will fail, so you either write the code (create  
the NSWindowController subclass, return the right result from its - 
windowNibName method) or work with a nib file (create a nib file with  
the right name, set your subclass as its owner, add a window to it  
and make a connection from the owner to the window).

Now you can write a test that verifies the window's content view  
contains a button, and that the button has the title and position and  
resize behaviors you expect.

Controls in Cocoa operate according to the target-action design  
pattern: each control can have a target object associated with it,  
and activating the control will send an action message to (i.e.  
invoke a named method on) that object.  So, to verify that when the  
button is clicked your -doSomething:, you can just check that the  
button has the appropriate target and action configured.  You can  
trust that the framework will do the right thing.

But even if you don't, you don't have to simulate an event queue or  
run loop.  You just need to invoke -performClick: on the button  
object and it will send its action to its target.

None of this, by the way, actually requires you to show the window.   
In fact, so long as you leave the "show on launch" flag on the window  
off, and don't invoke -showWindow: on your window controller, then no  
window will actually appear on the screen.

It winds up being quite easy to do test-driven development of human  
interfaces with Cocoa, because you can generally just test that  
everything is wired up right rather than that everything responds  
correctly to all the events in the right states.  And testing that  
things are wired up right is just a matter of knowing how to traverse  
the object graphs and asserting equality.

   -- Chris



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/