Somehow this got stuck in moderation?
http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2019-February/001419.html
Just a brief reply: Thunderbird has a bazillion of tests: MozMill tests to test the UI behaviour, Xpcshell tests to test the internal interfaces and Mochitests, which Geoff can tell us about.
All these can be seen working or failing at https://treeherder.mozilla.org/#/jobs?repo=comm-central
We couldn't survive without those tests since TB has thousands of functions we can't check manually on every release. Not all functions are covered by tests, but there are enough test that tell us if major functionality breaks.
The post below suggests adding keyboard tests. Some of our MozMill tests simulate some keyboard input.
Jörg.
Original post from Samuel Thibault sthibault at hypra.fr follows.
---
Hello,
AFAIK, Thunderbird doesn't currently include a testsuite.
For accessibility testing, we would like to introduce tests to check the
behavior at the user interface itself, by using dogtail (developped by
Fedora, based on at-spi) to simulate keypresses, mouse clicks, and check
the results.
The idea is that at Hypra, we have a well-established documentation
of what keyboard shortcut sequences blind users would employ to use
thunderbird, and which we should thus make sure always work. The key
sequences might have to be changed if that's for a good reason, but at
least we would know about it and update the documentation accordingly.
I have put a prototype of what we are thinking of on
<a href="https://git.hypra.fr/hypra/regression-testing/tree/master">https://git.hypra.fr/hypra/regression-testing/tree/master</a>
An example of what it would look like is:
pressCombo('<control><shift>k')
acc = app.child('Filter these messages <Ctrl+Shift+K>', 'entry')
waitFocus(acc)
pressCombo('<alt>f')
acc = app.child('New', 'menu')
waitFocus(acc)
etc.
which here allows to check that the control-shift-k shortcut properly
reaches the filter entry, that alt-f opens the file menu, etc.
I have written a "log" script that can generate such testcase code:
a user can run thunderbird and perform a usage scenario, and "log"
will get the interesting events from at-spi (keypresses, focus change,
checkbox status change, etc.) and emit the python code which simulates
keypresses and waits for the results. That way we can easily produce
testcases from our documentation, by just running the use cases
described in it, which are representative of what a blind user needs to
be able to do.
Dogtail depends on atspi, but also on python-cairo, python-gi,
gir1.2-gtk-3.0, I don't know if these could be included at least in the
Linux build environments, so such testsuite could be done regularly?
We (Hypra) could then feed thunderbird with such tests, from our
documentation. We can probably produce dozens of them, which can
probably be tested within something like a few minutes.
Samuel
On 08/03/2019 11:10, Jörg Knobloch wrote:
Somehow this got stuck in moderation?
Sorry, it wasn't, I used the wrong search term.
Hello,
Jörg Knobloch, le ven. 08 mars 2019 11:10:38 +0100, a ecrit:
Just a brief reply: Thunderbird has a bazillion of tests: MozMill tests to test
the UI behaviour, Xpcshell tests to test the internal interfaces and
Mochitests, which Geoff can tell us about.
The post below suggests adding keyboard tests. Some of our MozMill tests
simulate some keyboard input.
Ok, I thought there weren't keyboard UI tests. Now I could find
them. Writing them however seems relatively involved. E.g.
apparently to test for elements to get focused, one has to
check mc.window.document.commandDispatcher.focusedElement or
mc.window.top.document.activeElement, and I do not really know how to
easily get the widget that our tests would like to reach. Could they be
found with stable-over-development widget ids?
Put another way, overall the Thunderbird testing infrastructure doesn't
seem to allow us to easily write testing scenarii just from our user
testcases. Would it be possible to have the thunderbird testsuite
include a series using dogtail, whose interface is very close to what
the user actually interacts with, and thus allows us to very easily
write usercase tests? The overall testing time would probably be like
minutes.
Samuel