Re: [TDD] Advice for Swing GUI Testing?
- On Jul 31, 2004, at 5:59 AM, Peter Gummer wrote:
> Whether it's code or data, how does that change the problem? Data canActually, it's quite easy to notice the error if you're doing
> 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.
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@...>
- Phlip wrote:
>>One technique is Gold Master: build up the resourceI presume that the master resource file has labels in place of localized
>>file once, take a
>>snapshot, then check future versions against the
>>snapshot. If the
>>resource file changes, you'll know that it has
>>changed and can verify
>>that the change was intentional and correct. This
>>could be as simple as
>>a verbatim text file comparison.
> What if you use a text merging engine to localize an
> English RC file into a dozen other languages?
strings. Use Gold Master on that file.
I presume that you have translated files for each language. Use Gold
Master on each of those files.
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand