The new era of unit testing

[Edward K. Ream]

Yesterday I said that I was unlikely to create a new unit test for #2164, a Qt6-related bug.

When I awoke this morning I said, "Doh! I must do exactly that!" Indeed, I'll create a unit test that tests all the Qt enums listed in #1973.

Support for Qt unit tests

Commit b4791a adds support for Qt-based unit tests. There were a few complications, including screen flash. All such complications have been fixed.

BTW, I just realized that commit-related diffs are much easier to understand than the "global" diffs in PR's.

Most fixes involved adding guards on g.unitTesting. However, eventFilter crashed (after finishing all the tests!!) because g.app.gui no longer existed! No big deal. I just added a guard on g.app itself.

What happens in unit tests stays in unit tests?

I investigated calling create_app in setUp rather than in setUpClass, which would totally separate each unit test. However, test-all would take about one second longer. Imo, the extra time is not worthwhile. I've gotten addicted to fast unit tests!

To repeat, g.unitTesting is never true while running Leo itself. For the first time, guards on g.unitTesting are completely benign!

Work flow

The new unit testing framework is much, much, much, better than the old. I make a change to Leo's core and run test-all or one of the other test-* commands. This is the way test-driven development is supposed to work.  I do have to restart Leo when changing leoTest2.py, but that happens rarely.

Summary

Leo now can run unit tests using the Qt gui. Such unit tests do not show any Qt windows.

The new work flow makes test-driven development feasible, a major boost to productivity.

Edward