On Jul 31, 2004, at 5:59 AM, Peter Gummer wrote:
> Whether it's code or data, how does that change the problem? Data can
> go missing just as easily as a line of code.
> The point that being declarative makes the omission more obvious may be
> well taken. I'm not so sure that putting the data is in a separate file
> helps, though, because then it can be harder to notice the error.
Actually, it's quite easy to notice the error if you're doing
test-driven development regardless of whether you're using code or data
to generate your interface.
Let's say you're using data. I wouldn't write tests that look at the
data file that describes the interface itself. Rather, I would write
tests that instantiate the interface, and inspect how it's wired up in
as much detail as I need to be confident it's correct but no more. I'd
generally leave look and feel issues separate, and concentrate on the
For example, let's say I'm building a simple currency converter app. A
test case may load the interface in its -setUp method; this
automatically "wires up" everything. One test might look to see that
there's a button wired up to the application controller's
"convertButton" instance variable (which in Cocoa we call an "outlet"
when used like this), and check that the button has its target & action
method set to the controller and -convert: respectively.
Another test may see whether there is a text field with a proper
currency formatter connected to the controller's "convertFrom" outlet.
Another may test whether there's an "exchangeRate" text field, and so
on. Still more tests may check whether my actual conversion logic
works, and whether things are wired up in such a way that the right
input and output will happen between that logic and the interface.
I'm not really writing code to check the individual frame rectangles of
the controls or anything like that, just that they exist and are wired
up like the rest of the code I'm about to write will expect.
Chris Hanson <cmh@...