[Testing] Automated testing, OLPC, code+screencasts.

[Charles Merriam]

Hello Titus,

Good to see you at PyCon.  Here's a random idea I think would be
worthwhile, if it could work well into the Sugar-gui or even the other
subsystems of Sugar.

Tooting my own horn today,

Charles Merriam

===
http://www.charlesmerriam.com/blog/?p=106
Problem:  Testing GUIs tends to be hard.

Writing a reasonable test for GUIs usually involves contortions to
find the correct widget and values.  For example, a test might want to
confirm that "the font is now bold for the third text field, named
system_danger_level, in the hbox in the floating frame in the second
panel in the third tab bar in the dialog box".  Figuring out how to
tell if the test passed is usually difficult.

Solution:  Add a function in the GUI framework that returns a single
large data structure for the state of the GUI.  Use standard Python
programming to navigate it.

The test becomes:

assert(gobject.dump("system_danger_level")["font"]["style"] == "bold")

This is one of my poorly researched ideas:  it came up while talking
with Shandy before Mark Shuttleworth's talk last night.  All GUI
frameworks are inherently a bit crufty and hard to navigate.  On the
other hand, the data types in Python are rich:  dictionaries, arrays,
nested structures, etc.   While handing such a data structure to PyGTK
to modify the GUI might require a lot of writing, asking PyGTK to
disgorge such a data structure is far easier.

Consider adding it the the GObject functions.  Call a new
gobject.dump_main_context() and get a huge Python data structure back.
 It might have lots of redundant methods of finding the same data.
For example, a tree of all the contexts or dialog boxes and the usual
tree objects inside that are grabbed by tools like Guitar's GUI
Ripper.  It might also have a handy hash of object id's and their
associated sub-records, like an index into the big tree.

While some may decry the memory and time cost of creating this tree
might have the legitimate wish for a second function known simply as
gobject.dump().  It would take a single identifier tag and return a
single object from that tag 'downwards' in detail.  A well published
heuristic would have it "do the right thing" when given a tag that
exists in multiple places.
This feels like a "implement it first and then see if its useful" type of hack.


On Wed, Mar 26, 2008 at 12:31 AM, Titus Brown <titus at caltech.edu> wrote:
> Hi all,
>
>  I'm delurking with a vengeance here, I think :).
>  ...  I would
>  very much like to try to introduce systematic and robust GUI testing
>  into the OLPC and I will be working towards that end as time and
>  resources permit.  Constructive comments and genuine interest are
>  welcome!
>
>  cheers,
>  --titus
>  -----------------------------
>
>  Dr. C. Titus Brown, ctb at msu.edu
>  Asst Prof., Michigan State U.
>  http://ged.cse.msu.edu/
>  _______________________________________________
>  Testing mailing list
>  Testing at lists.laptop.org
>  http://lists.laptop.org/listinfo/testing
>  _______________________________________________
>  Devel mailing list
>  Devel at lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>