Considera este código:

public void actionPerformed(ActionEvent e) {
    setEnabled(false);
    new SwingWorker<File, Void>() {

        private String location = url.getText();

        @Override
        protected File doInBackground() throws Exception {
            File file = new File("out.txt");
            Writer writer = null;
            try {
                writer = new FileWriter(file);
                creator.write(location, writer);
            } finally {
                if (writer != null) {
                    writer.close();
                }
            }
            return file;
        }

        @Override
        protected void done() {
            setEnabled(true);
            try {
                File file = get();
                JOptionPane.showMessageDialog(FileInputFrame.this,
                    "File has been retrieved and saved to:\n"
                    + file.getAbsolutePath());
                Desktop.getDesktop().open(file);
            } catch (InterruptedException ex) {
                logger.log(Level.INFO, "Thread interupted, process aborting.", ex);
                Thread.currentThread().interrupt();
            } catch (ExecutionException ex) {
                Throwable cause = ex.getCause() == null ? ex : ex.getCause();
                logger.log(Level.SEVERE, "An exception occurred that was "
                    + "not supposed to happen.", cause);
                JOptionPane.showMessageDialog(FileInputFrame.this, "Error: "
                    + cause.getClass().getSimpleName() + " "
                    + cause.getMessage(), "Error", JOptionPane.ERROR_MESSAGE);
            } catch (IOException ex) {
                logger.log(Level.INFO, "Unable to open file for viewing.", ex);
            }
        }
    }.execute();

url es un JTextField y 'creador' es una interfaz inyectada para escribir el archivo (para que esa parte esté bajo prueba). La ubicación donde se escribe el archivo está codificada a propósito porque esto se pretende como un ejemplo. Y java.util.logging se usa simplemente para evitar una dependencia externa.

¿Cómo podría dividir esto para que sea comprobable por la unidad (incluido el abandono de SwingWorker si es necesario, pero luego reemplazar su funcionalidad, al menos como se usa aquí).

Desde mi punto de vista, doInBackground está básicamente bien. La mecánica fundamental es crear un escritor y cerrarlo, lo cual es casi demasiado simple de probar y el trabajo real está bajo prueba. Sin embargo, el método realizado es problemático entre comillas, incluido su acoplamiento con el método actionPerformed de la clase principal y la coordinación de la activación y desactivación del botón.

Sin embargo, separar eso no es obvio. Inyectar algún tipo de SwingWorkerFactory hace que la captura de los campos de la GUI sea mucho más difícil de mantener (es difícil ver cómo sería una mejora del diseño). JOpitonPane y Desktop tienen toda la "bondad" de Singletons, y el manejo de excepciones hace que sea imposible ajustarlo fácilmente.

Entonces, ¿cuál sería una buena solución para probar este código?