Re: Trust, but verify - OCUnit testing of Target-Action Connections
Re: Trust, but verify - OCUnit testing of Target-Action Connections
- Subject: Re: Trust, but verify - OCUnit testing of Target-Action Connections
- From: "David H. Silber" <email@hidden>
- Date: Mon, 12 Jan 2009 16:03:10 -0500
On Sun, Jan 11, 2009 at 09:56:19PM -0800, Chris Hanson wrote:
> On Jan 11, 2009, at 2:49 PM, David H. Silber wrote:
>
> >I have created a trivial Cocoa Application, with trivial model and
> >controller classes, and with a view built in Interface Builder. The
> >application changes its window title when its button is pressed, so
> >it obviously can load its window and is able to send messages to it.
> >
> >I can't test it though, because I'm unable to get the window loaded
> >by/for the tests. The -testWindowLoading test, which I swiped from
> >Mr. Hanson's article fails.
> It's failing because while you created an NSWindowController subclass
> to manage your window, you didn't actually create a nib to go along
> with it. Instead, you're just re-using your application's nib.
Ah! So I give my controller its own nib (with appropriate connections)
and the tests pass. Instantiating the controller in my application
makes it load the its nib(1) and then sending the window a -display
message gets this tested window started. I deleted the window from the
MainMenu.xib, so that empty window is not in the way, and all is well.
A couple of things still bother me:
1) Is there not any way to test the connections set up in the nib
owned by the application? In particular, the menus.(2)
As things stand, I still end up with a bunch of untestable code.
2) It seems like creating my own window and replacing the window
provided by the application's nib is subverting the Cocoa frameworks.
Or perhaps I'm taking your suggestion and applying it sideways?
> A window controller should be File's Owner of the nib containing its
> window, and should have its window outlet set to refer to the window
> in the nib file.
This is a helpful explanation that led me to a number of useful
discussions and documents.
Thanks,
David
(1) Thanks to your mention of -initWithWindowNibName in your test
comments, without which I might still be searching for how to do this.
(2) I'm under the impression that only the application can have a menu
bar, so I can't do the same trick of replacing the menus, but perhaps
you know some other way around this.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden