Upgrade our test suite to Dogtail 2

intrigeri
2026-04-07T07:54:24Z

Debian 14 (Forky) will likely have Dogtail 2:

* https://gitlab.com/dogtail/dogtail/-/issues/29
* https://gitlab.com/dogtail/dogtail/-/merge_requests/57

Starting point for this work: d8292602c2a04522fb36f3171366f7831f64c623 from [`21431...

Debian 14 (Forky) will likely have Dogtail 2:

https://gitlab.com/dogtail/dogtail/-/issues/29

https://gitlab.com/dogtail/dogtail/-/merge_requests/57

Starting point for this work: d8292602 from 21431-dogtail-2.x for Draft: Test dogtail 2.0.2 (!2886 - closed) (patch just in case: Test-suite-adapt-for-dogtail-2.patch)

In Ensure Dogtail 2 works for our needs, before th... (#21431 - closed) we found some issues (many which has rudimentary/ugly fixes in the above mentioned commit):

Some things are renamed, like findChild() → find_child(), but findChild() is still there for backwards-compatibility but it only supports the retry kwarg so it's not sufficient for our needs. Whatever, we should migrate to the new methods that support everything.

There's some very verbose failures about logging not working (I/O operation on closed file), perhaps related to that the log file is used by multiple users? Can be disabled with import dogtail.logging; dogtail.logging.logging.disable(). I don't think these cause the code we run to fail, though.

Markup like ... no longer is part of the node names, so we must drop that in the few places it's used (e.g. 'Connect to Tor _automatically' → 'Connect to Tor _automatically').

Something is wrong with how we deal with single quotes in strings for generated python code (which we must since we use single quotes for strings) in Dogtail::Node.value_to_s(). We used to do gsub("'", "\\\\'") but it doesn't work, however I tried gsub("'", "'+\"'\"+'") and that works.

Regex matching for node names was dropped, and we use it in a few places. We can solve it on our side by e.g. searching for all children of the same role, and then children.find(proc { raise Dogtail::Failure }) { |n| regex.match(n.name) }.

Something is different about how "\n" in ruby strings is translated to python strings, in one instance I just switched (on the ruby side) from single quotes to double quotes and then it worked. I am sure there is a nice solution.

Unicode characters like "…" actually work now, so our workaround (like \u2026) actually break things and should be dropped.