Java: ¿Cómo probar métodos que llaman a System.exit ()?

Tengo algunos métodos que deberían invocar System.exit()ciertas entradas. Desafortunadamente, probar estos casos hace que JUnit termine. Poner las llamadas al método en un nuevo hilo no parece ayudar, ya queSystem.exit() termina la JVM, no solo el hilo actual. ¿Hay algún patrón común para lidiar con esto? Por ejemplo, ¿puedo sustituir un trozo System.exit()?

[EDITAR] La clase en cuestión es en realidad una herramienta de línea de comandos que estoy intentando probar dentro de JUnit. ¿Quizás JUnit simplemente no es la herramienta adecuada para el trabajo? Las sugerencias para herramientas de prueba de regresión complementarias son bienvenidas (preferiblemente algo que se integre bien con JUnit y EclEmma).

De hecho, Derkeiler.com sugiere:

• ¿Por qué System.exit()?

En lugar de terminar con System.exit (whateverValue), ¿por qué no lanzar una excepción no marcada? En uso normal, se desplazará hasta el último receptor de la JVM y cerrará su script (a menos que decida atraparlo en algún lugar del camino, lo que podría ser útil algún día).

En el escenario JUnit, será capturado por el marco JUnit, que informará que tal y tal prueba falló y avanzará sin problemas a la siguiente.

• Evite System.exit()salir de la JVM:

Intente modificar el TestCase para que se ejecute con un administrador de seguridad que evite llamar a System.exit, luego capture la SecurityException.

public class NoExitTestCase extends TestCase 
{

    protected static class ExitException extends SecurityException 
    {
        public final int status;
        public ExitException(int status) 
        {
            super("There is no escape!");
            this.status = status;
        }
    }

    private static class NoExitSecurityManager extends SecurityManager 
    {
        @Override
        public void checkPermission(Permission perm) 
        {
            // allow anything.
        }
        @Override
        public void checkPermission(Permission perm, Object context) 
        {
            // allow anything.
        }
        @Override
        public void checkExit(int status) 
        {
            super.checkExit(status);
            throw new ExitException(status);
        }
    }

    @Override
    protected void setUp() throws Exception 
    {
        super.setUp();
        System.setSecurityManager(new NoExitSecurityManager());
    }

    @Override
    protected void tearDown() throws Exception 
    {
        System.setSecurityManager(null); // or save and restore original
        super.tearDown();
    }

    public void testNoExit() throws Exception 
    {
        System.out.println("Printing works");
    }

    public void testExit() throws Exception 
    {
        try 
        {
            System.exit(42);
        } catch (ExitException e) 
        {
            assertEquals("Exit status", 42, e.status);
        }
    }
}

Actualización de diciembre de 2012:

Will propone en los comentarios usando las Reglas del sistema , una colección de reglas JUnit (4.9+) para probar el código que usa java.lang.System.
Esto fue mencionado inicialmente por Stefan Birkner en su respuesta en diciembre de 2011.

System.exit(…)

Use la ExpectedSystemExitregla para verificar que System.exit(…)se llama.
También puede verificar el estado de salida.

Por ejemplo:

public void MyTest {
    @Rule
    public final ExpectedSystemExit exit = ExpectedSystemExit.none();

    @Test
    public void noSystemExit() {
        //passes
    }

    @Test
    public void systemExitWithArbitraryStatusCode() {
        exit.expectSystemExit();
        System.exit(0);
    }

    @Test
    public void systemExitWithSelectedStatusCode0() {
        exit.expectSystemExitWithStatus(0);
        System.exit(0);
    }
}

La biblioteca System Lambda tiene un método. catchSystemExitCon esta regla puedes probar el código, que llama a System.exit (...):

public void MyTest {
    @Test
    public void systemExitWithArbitraryStatusCode() {
        SystemLambda.catchSystemExit(() -> {
            //the code under test, which calls System.exit(...);
        });
    }
}

Para Java 5 a 7, la biblioteca System Rules tiene una regla JUnit llamada ExpectedSystemExit. Con esta regla, puede probar el código, que llama a System.exit (...):

public void MyTest {
    @Rule
    public final ExpectedSystemExit exit = ExpectedSystemExit.none();

    @Test
    public void systemExitWithArbitraryStatusCode() {
        exit.expectSystemExit();
        //the code under test, which calls System.exit(...);
    }

    @Test
    public void systemExitWithSelectedStatusCode0() {
        exit.expectSystemExitWithStatus(0);
        //the code under test, which calls System.exit(0);
    }
}

Divulgación completa: soy el autor de ambas bibliotecas.

¿Qué hay de inyectar un "ExitManager" en estos métodos:

public interface ExitManager {
    void exit(int exitCode);
}

public class ExitManagerImpl implements ExitManager {
    public void exit(int exitCode) {
        System.exit(exitCode);
    }
}

public class ExitManagerMock implements ExitManager {
    public bool exitWasCalled;
    public int exitCode;
    public void exit(int exitCode) {
        exitWasCalled = true;
        this.exitCode = exitCode;
    }
}

public class MethodsCallExit {
    public void CallsExit(ExitManager exitManager) {
        // whatever
        if (foo) {
            exitManager.exit(42);
        }
        // whatever
    }
}

El código de producción usa ExitManagerImpl y el código de prueba usa ExitManagerMock y puede verificar si se llamó a exit () y con qué código de salida.

En realidad, puedes burlarte o descartar el System.exitmétodo, en una prueba JUnit.

Por ejemplo, usando JMockit podría escribir (también hay otras formas):

@Test
public void mockSystemExit(@Mocked("exit") System mockSystem)
{
    // Called by code under test:
    System.exit(); // will not exit the program
}

EDITAR: Prueba alternativa (utilizando la última API de JMockit) que no permite que se ejecute ningún código después de una llamada a System.exit(n):

@Test(expected = EOFException.class)
public void checkingForSystemExitWhileNotAllowingCodeToContinueToRun() {
    new Expectations(System.class) {{ System.exit(anyInt); result = new EOFException(); }};

    // From the code under test:
    System.exit(1);
    System.out.println("This will never run (and not exit either)");
}

Un truco que utilizamos en nuestra base de código fue hacer que la llamada a System.exit () se encapsulara en un impl Runnable, que el método en cuestión usaba por defecto. Para la prueba unitaria, establecemos un simulacro de Runnable diferente. Algo como esto:

private static final Runnable DEFAULT_ACTION = new Runnable(){
  public void run(){
    System.exit(0);
  }
};

public void foo(){ 
  this.foo(DEFAULT_ACTION);
}

/* package-visible only for unit testing */
void foo(Runnable action){   
  // ...some stuff...   
  action.run(); 
}

... y el método de prueba JUnit ...

public void testFoo(){   
  final AtomicBoolean actionWasCalled = new AtomicBoolean(false);   
  fooObject.foo(new Runnable(){
    public void run(){
      actionWasCalled.set(true);
    }   
  });   
  assertTrue(actionWasCalled.get()); 
}

Cree una clase simulable que envuelva System.exit ()

Estoy de acuerdo con EricSchaefer . Pero si usa un buen marco de imitación como Mockito, una clase concreta simple es suficiente, no necesita una interfaz y dos implementaciones.

Detener la ejecución de la prueba en System.exit ()

Problema:

// do thing1
if(someCondition) {
    System.exit(1);
}
// do thing2
System.exit(0)

Una burla Sytem.exit()no terminará la ejecución. Esto es malo si quieres probar esothing2 no se ejecuta.

Solución:

Deberías refactorizar este código como lo sugiere Martin :

// do thing1
if(someCondition) {
    return 1;
}
// do thing2
return 0;

Y hacer System.exit(status)en la función de llamada. Esto te obliga a tener todas tus System.exit()direcciones en un solo lugar en o cerca main(). Esto es más limpio que llamarSystem.exit() profundamente dentro de su lógica.

Código

Envoltura:

public class SystemExit {

    public void exit(int status) {
        System.exit(status);
    }
}

Principal:

public class Main {

    private final SystemExit systemExit;


    Main(SystemExit systemExit) {
        this.systemExit = systemExit;
    }


    public static void main(String[] args) {
        SystemExit aSystemExit = new SystemExit();
        Main main = new Main(aSystemExit);

        main.executeAndExit(args);
    }


    void executeAndExit(String[] args) {
        int status = execute(args);
        systemExit.exit(status);
    }


    private int execute(String[] args) {
        System.out.println("First argument:");
        if (args.length == 0) {
            return 1;
        }
        System.out.println(args[0]);
        return 0;
    }
}

Prueba:

public class MainTest {

    private Main       main;

    private SystemExit systemExit;


    @Before
    public void setUp() {
        systemExit = mock(SystemExit.class);
        main = new Main(systemExit);
    }


    @Test
    public void executeCallsSystemExit() {
        String[] emptyArgs = {};

        // test
        main.executeAndExit(emptyArgs);

        verify(systemExit).exit(1);
    }
}

Me gustan algunas de las respuestas ya dadas, pero quería demostrar una técnica diferente que a menudo es útil cuando se pone a prueba el código heredado. Código dado como:

public class Foo {
  public void bar(int i) {
    if (i < 0) {
      System.exit(i);
    }
  }
}

Puede realizar una refactorización segura para crear un método que envuelva la llamada System.exit:

public class Foo {
  public void bar(int i) {
    if (i < 0) {
      exit(i);
    }
  }

  void exit(int i) {
    System.exit(i);
  }
}

Luego puede crear una falsificación para su prueba que anule la salida:

public class TestFoo extends TestCase {

  public void testShouldExitWithNegativeNumbers() {
    TestFoo foo = new TestFoo();
    foo.bar(-1);
    assertTrue(foo.exitCalled);
    assertEquals(-1, foo.exitValue);
  }

  private class TestFoo extends Foo {
    boolean exitCalled;
    int exitValue;
    void exit(int i) {
      exitCalled = true;
      exitValue = i;
    }
}

Esta es una técnica genérica para sustituir el comportamiento de los casos de prueba, y lo uso todo el tiempo al refactorizar el código heredado. Por lo general, no es donde voy a dejar las cosas, sino un paso intermedio para probar el código existente.

Un vistazo rápido a la API muestra que System.exit puede lanzar una excepción especialmente. si un administrador de seguridad prohíbe el cierre de la máquina virtual. Tal vez una solución sería instalar dicho administrador.

Puede usar Java SecurityManager para evitar que el subproceso actual apague la máquina virtual Java. El siguiente código debe hacer lo que quieras:

SecurityManager securityManager = new SecurityManager() {
    public void checkPermission(Permission permission) {
        if ("exitVM".equals(permission.getName())) {
            throw new SecurityException("System.exit attempted and blocked.");
        }
    }
};
System.setSecurityManager(securityManager);

Para que la respuesta de VonC se ejecute en JUnit 4, modifiqué el código de la siguiente manera

protected static class ExitException extends SecurityException {
    private static final long serialVersionUID = -1982617086752946683L;
    public final int status;

    public ExitException(int status) {
        super("There is no escape!");
        this.status = status;
    }
}

private static class NoExitSecurityManager extends SecurityManager {
    @Override
    public void checkPermission(Permission perm) {
        // allow anything.
    }

    @Override
    public void checkPermission(Permission perm, Object context) {
        // allow anything.
    }

    @Override
    public void checkExit(int status) {
        super.checkExit(status);
        throw new ExitException(status);
    }
}

private SecurityManager securityManager;

@Before
public void setUp() {
    securityManager = System.getSecurityManager();
    System.setSecurityManager(new NoExitSecurityManager());
}

@After
public void tearDown() {
    System.setSecurityManager(securityManager);
}

Puede probar System.exit (..) reemplazando la instancia de Runtime. Por ejemplo, con TestNG + Mockito:

public class ConsoleTest {
    /** Original runtime. */
    private Runtime originalRuntime;

    /** Mocked runtime. */
    private Runtime spyRuntime;

    @BeforeMethod
    public void setUp() {
        originalRuntime = Runtime.getRuntime();
        spyRuntime = spy(originalRuntime);

        // Replace original runtime with a spy (via reflection).
        Utils.setField(Runtime.class, "currentRuntime", spyRuntime);
    }

    @AfterMethod
    public void tearDown() {
        // Recover original runtime.
        Utils.setField(Runtime.class, "currentRuntime", originalRuntime);
    }

    @Test
    public void testSystemExit() {
        // Or anything you want as an answer.
        doNothing().when(spyRuntime).exit(anyInt());

        System.exit(1);

        verify(spyRuntime).exit(1);
    }
}

Hay entornos en los que el programa de llamada utiliza el código de salida devuelto (como ERRORLEVEL en MS Batch). Tenemos pruebas en torno a los principales métodos que hacen esto en nuestro código, y nuestro enfoque ha sido utilizar una anulación de SecurityManager similar a la utilizada en otras pruebas aquí.

Anoche armé un pequeño JAR usando las anotaciones de Junit @Rule para ocultar el código del administrador de seguridad, así como para agregar expectativas basadas en el código de retorno esperado. http://code.google.com/p/junitsystemrules/

La mayoría de las soluciones lo harán

• terminar la prueba (método, no toda la ejecución) System.exit()se llama el momento
• ignorar un ya instalado SecurityManager
• A veces sea bastante específico para un marco de prueba
• restringir para ser utilizado al máximo una vez por caso de prueba

Por lo tanto, la mayoría de las soluciones no son adecuadas para situaciones en las que:

• La verificación de los efectos secundarios se realizará después de la llamada a System.exit()
• Un administrador de seguridad existente es parte de las pruebas.
• Se utiliza un marco de prueba diferente.
• Desea tener múltiples verificaciones en un solo caso de prueba. Esto puede no ser estrictamente recomendado, pero a veces puede ser muy conveniente, especialmente en combinación con assertAll(), por ejemplo.

No estaba contento con las restricciones impuestas por las soluciones existentes presentadas en las otras respuestas y, por lo tanto, se me ocurrió algo por mi cuenta.

La siguiente clase proporciona un método assertExits(int expectedStatus, Executable executable)que afirma que System.exit()se llama con un statusvalor especificado , y la prueba puede continuar después. Funciona de la misma manera que JUnit 5 assertThrows. También respeta a un administrador de seguridad existente.

Hay un problema restante: cuando el código bajo prueba instala un nuevo administrador de seguridad que reemplaza completamente al administrador de seguridad establecido por la prueba. Todas las otras SecurityManagersoluciones basadas en mí que conozco sufren el mismo problema.

import java.security.Permission;

import static java.lang.System.getSecurityManager;
import static java.lang.System.setSecurityManager;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.fail;

public enum ExitAssertions {
    ;

    public static <E extends Throwable> void assertExits(final int expectedStatus, final ThrowingExecutable<E> executable) throws E {
        final SecurityManager originalSecurityManager = getSecurityManager();
        setSecurityManager(new SecurityManager() {
            @Override
            public void checkPermission(final Permission perm) {
                if (originalSecurityManager != null)
                    originalSecurityManager.checkPermission(perm);
            }

            @Override
            public void checkPermission(final Permission perm, final Object context) {
                if (originalSecurityManager != null)
                    originalSecurityManager.checkPermission(perm, context);
            }

            @Override
            public void checkExit(final int status) {
                super.checkExit(status);
                throw new ExitException(status);
            }
        });
        try {
            executable.run();
            fail("Expected System.exit(" + expectedStatus + ") to be called, but it wasn't called.");
        } catch (final ExitException e) {
            assertEquals(expectedStatus, e.status, "Wrong System.exit() status.");
        } finally {
            setSecurityManager(originalSecurityManager);
        }
    }

    public interface ThrowingExecutable<E extends Throwable> {
        void run() throws E;
    }

    private static class ExitException extends SecurityException {
        final int status;

        private ExitException(final int status) {
            this.status = status;
        }
    }
}

Puedes usar la clase así:

    @Test
    void example() {
        assertExits(0, () -> System.exit(0)); // succeeds
        assertExits(1, () -> System.exit(1)); // succeeds
        assertExits(2, () -> System.exit(1)); // fails
    }

El código se puede portar fácilmente a JUnit 4, TestNG o cualquier otro marco, si es necesario. El único elemento específico del marco está fallando la prueba. Esto se puede cambiar fácilmente a algo independiente del marco (que no sea un Junit 4 Rule

Hay margen de mejora, por ejemplo, sobrecarga de assertExits()mensajes personalizables.

Use Runtime.exec(String command)para iniciar JVM en un proceso separado.

Hay un pequeño problema con la SecurityManagersolución. Algunos métodos, como JFrame.exitOnClose, también llaman SecurityManager.checkExit. En mi solicitud, no quería que la llamada fallara, así que usé

Class[] stack = getClassContext();
if (stack[1] != JFrame.class && !okToExit) throw new ExitException();
super.checkExit(status);

Llamar a System.exit () es una mala práctica, a menos que se haga dentro de un main (). Estos métodos deberían arrojar una excepción que, en última instancia, es captada por su main (), que luego llama a System.exit con el código apropiado.