Automatically testing a GUI is complicated. Indeed, the method you call when you open the GUI does not return until the main window is closed. A natural idea would then be to open the main window in a Thread, and create the tests in another one. But in (py)Qt, every things related to the GUI must occur in the main thread, which make this threading idea impossible.
Another easy solution would be to write the test inside the software, and use an option, or a global variable, to tell that you want to test the software once it's opened. This would work, but it means the test code is inside the software code, which is not beautiful.
One nice thing with anki is that it has an add-on system, which means that you can execute arbitrary code without having this code in anki. So, this is what I did. My test tells anki to start with a non-standard main folder. This folder contains a collection used for the test, and one add-on. The real tests are then in the add-on code. I thus tell the add-on to catch any exception and then to close the program with a non-zero exit code. My main test file only have to test that the execution of anki returns a 0 code.
Of course, if there is some unexpected problem, which allows windows to be opened and not to be closed, then anki will be stuck. But at least, seing anki stuck will show that there is a trouble. And an automated test system will simply fail because the test takes too much time.