[Pythoncard-users] fwd: RE: [Anygui-devel] Re: Automating UI tests (was Re: Art of Unit Testing)

[Kevin A. <al...@se...>]

> Alex Martelli wrote:

> I was imagining a scheme that would avoid the whole
> "move-one-button-and-break-stuff" thing. If widgets have
> names, which it seems they might based on recent list
> traffic, then I'd like to be able to write unit tests
> like this:
>
> # Open a customer window and load some data.
> win = TestWidgetCollection["CustDBWindow"]
> win.open()
> win["CustNameField"].typeKeys("Joe Smith")
> win["CustFetchButton"].click()
>
> # Confirm data loaded.
> if win["CustZipField"].getText() != "10001":
> 	... test failed ...

Having unit testing from day one should be a big win.

I think I would just use assert, but you have the general idea. We had
widgets sending events to each other (button2 sending a mouseClick to
button1 in the proof), but Rowland turned it off since it was "unclean". The
way our event dispatch works it will be trivial to add an event log, which
we're already doing via the Message Watcher, we're just not saving the
results or showing the details right now. It will also be relatively simple
to add a generic "macro" mechanism, which in turn can be used as part of the
testing framework. You'll also be able to post events to see if they are
actually handled such as click at position (45, 10).

Since I want PythonCard to support editing outside the environment (like
we're doing today) we will always need tools that make sure the code and
resources and data repository are in sync. The environment we eventually
create can do this transparently, but if we allow people to edit code in
Emacs or another IDE then it becomes possible to mismatch a handler name and
widget name and so there has to be an external validation process.

> This way, test cases would be independent
> of the exact layout of UI controls. Of course,
> if the overall structure of your UI changed,
> tests would break; but that's probably what
> you want. Also, I think test cases constructed
> this way will be easier to understand. (Hmm,
> maybe capture/playback could just generate
> code like this, to which one would only need
> to add commentary. That would rock.)
>
> This could also provide a general way of scripting
> Anygui apps, if anyone thought that would be useful.
>

Macros, yes. Note that via PyCrust we already have the ability run any
arbitrary Python code when an app is started. This is used in the turtle
sample and the base package to preload to short variable names (bg and
comp). In order to automate the edit, run, test, cycle you can actually
create a pycrustrc.py file in the app directory and then when you start the
app it will run the test. This should be formalized, but the capability is
already there. Anyway, I think this is pretty fundamental stuff.

Anyway, wxPython doesn't do this for us, but a higher-level pythonic
framework should probably support these kinds of things out of the gate.

ka