The context is here is unit testing: at the end of a test, at tearDown, if a JFileChooser is left "hanging" (i.e. displayed), I want to force it to return with a "Cancelled" value.
The problem is that, otherwise, the actionPerformed() where I've called showOpenDialog (a blocking method) continues to live on... I need to close down that Runnable.
NB the Runnable running actionPerformed is of course running in the EDT. But despite this, the framework is capable of starting another "event pump": my understanding is that this is the quite normal and correct behaviour when you do JFileChooser.showOpenDialog in the EDT: similar functioning to calling one of the JOptionPane.showXXX static methods in the EDT.
I also want to avoid a "testing-contrived" solution to this: in other words, the application code must be sufficient for itself, and not use tortuous or unnatural mechanisms in the knowledge that it is going to be run by testing code for which it needs to provide a "handle".
PS I am actually using Jython, rather than Java, and I am using the Python unittest module, rather than a Java-based unit testing framework. But this doesn't change the principles involved...
Aucun commentaire:
Enregistrer un commentaire