CI: run unittests after build

[swt2c]

There are probably going to be failures, but would be good to know where we are.

[echoix]

For the hanging test, what is the pattern that should be used when running without an user interaction?

In the following, showing a modal dialog has no apparent way of getting closed.

Phoenix/unittests/test_filedlgcustomize.py

Lines 9 to 22 in 5abeba2

	def test_filedlgcustomize1(self):
	class MyFileDialogCustomizeHook(wx.FileDialogCustomizeHook):
	def __init__(self):
	super().__init__()
	self.add_called = False
	def AddCustomControls(self, customizer):
	self.add_called = True
	hook = MyFileDialogCustomizeHook()
	dlg = wx.FileDialog(None, 'Save Document', '', 'file.my')
	dlg.SetCustomizeHook(hook)
	wx.CallLater(250, dlg.EndModal, wx.ID_OK)
	dlg.ShowModal()
	assert(hook.add_called)

[swt2c]

@echoix this line should cause the modal to be closed after 250 ms (I think):

wx.CallLater(250, dlg.EndModal, wx.ID_OK)

I haven't investigated yet why the Windows tests are hanging - is this the reason?

[echoix]

If it were to be a deadlock caused by multiprocessing and the startup method, we might've been able to see something similar on macOS too. Was the job retried and jams at the same place?

[echoix]

Last time I debugged something similar, I had to go by bisection to find what test where actually causing to jam, as it's not always the ones we see. If I remember correctly, there was also something to do with the fact that the shell used in the CI was cmd, and is quite limited on error reporting. The test was already failed, but the error didn't display yet, waiting for some input on some stream, and then times out, and further gets force killed (when seeing the ^C).

It's probably not as worse as it looks like.