Re: Re: A better way to test the GUI?

Charlie Poole wrote:
> 
> Hi Phlip,
> 
> > Divide all of TFUI into two kinds: Reusing controls that
> > animate data (such as edit fields and combo boxes), and
> > building new controls that animate data (such as heat maps,
> > contour maps, etc.).
> 
> As well as much more mundane controls... at least in markets
> where the appearance of ui elements is considered important.

That's the thing: When mundane controls provide an "ownerdraw" system,
they provide back-doors to override part of their paint events.
(That's how your Windows XP window title bars can look like fish
tanks, folks...)

But painting efficiently requires non-retained graphics, so you are
back to either letting testing slide, or using Mock Graphics.

If you just need a stoopid gradient inside a pushbutton, forget test-first.

> > To build a new control, you can use a canvas control, or you
> > can use raw paint commands. The latter is typically
> > "non-retained", so you must work extra to retain those
> > graphic commands, so tests can query they were on track.
> >
> > When a canvas control treats graphic commands as objects, it
> > can, for example, create a rectangle, and then seamlessly
> > move that rectangle around, change its attributes, etc. The
> > canvas handles the low-level details, including retaining
> > commands. The rectangle is an object, with properties to
> > query. This makes test-first very very easy.
> 
> So a canvas control is equivalent to what I refered to as "creating
> an intermediate layer" - a particular kind of layer that retains the
> created objects. I agree that this is a really good approach and
> I use it a lot when there's a good reason - for cases such as you
> described. I'll note however that depending on the existence of such
> an object for testing does beg the question. After all, you have to
> test the canvas control, don't you?

Not if someone else wrote it. The goal is to test-_first_ your custom control.

> But that wasn't my main point anyway. The part of your note I was
> answering wasn't about canvas controls at all. It was this...

I keep bringing up canvas controls because they are the easier kind of
custom control.

> > Do you need the Java / C# version? That's roughly...
> >
> >    void Paint(Graphic g);
> >
> > Now the GUI Toolkit calls Paint whenever the window updates, and the
> programmer overrides Paint() and
> > uses g with primitive brush and paint commands. A "Mock Graphics"
> effort will supply a mock g, and
> > record all the calls. Then a Log String Test can query the calls out
> of g and roughly ensure they were correct.
> 
> I just wanted to make it clear that this really  isn't as easy (at least
> in C#) as you make
> it sound.The reasons are in my earlier post.

Don't even try it if it's easy. (Or introduce delegation.)

For MS Windows, wouldn't both Java and C# GUIs support GDI calls to
create a metafile?

-- 
Phlip


 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
    [email protected]

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