Automated testing of activities
Jim Gettys
jg at laptop.org
Tue Jul 17 15:36:33 EDT 2007
I want to give everyone a heads up to start thinking about the following
issues:
1) we need to be able to do basic automated smoke testing of activities.
2) we need to support accessibility in activities. Some of you may not
be aware of it, but this is a non-optional requirement of some
jurisdiction, most of which roughly follow US government laws in this
area.
3) we need to be able to quantify improvements/regressions in activity's
energy usage, as we optimize various code in our system.
4) we need to be able to automate testing of realistic workloads (or
play loads :-), of our systems that roughly simulate the use of a child
in school, so we can see how we're doing when we change various knobs
that we have for controlling power usage, from backlight, to use of the
dcon, to blanking the screen, to suspending aggressively, etc.
Applications adding hints in key locations that suspending might be a
good thing to do are also becoming possible, as our power management
infrastructure improves.
But if we can't reproduce results, we'll be in fog, unable to see what
direction to go.
We'll therefore need to be able to script applications. So long as
we're on an XO-1 with its resolution screen *and* you don't change the
UI, it's not all that hard. But we expect all of you to want to tune
your UI's, and also we need to ensure accessibility needs get met.
Future systems our software runs on may have different screens; this
model will break down pretty quickly.
Note that the hooks required for accessibility hooks makes it possible
to script activities by name, rather than by X/Y coordinates on the
screen, and wait for results, and that this technology therefore can
remove the screen resolution dependence of such scripting. Custom
widgets you build will need such hooks, in any case.
We'll shortly be setting up a battery life testing infrastructure in a
revived Tinderbox; with the machine we have with instrumented with > 20
measurement points we can gather great amounts of useful information on
the behavior of our system and of individual activities.
At some point, we'll start asking you to generate a workload for an
activity, which should be able to address many of the issues above.
More when the infrastructure work is further along.
- Jim
--
Jim Gettys
One Laptop Per Child
More information about the Devel
mailing list