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

Tengo algunos métodos que deberían llamar System.exit() en ciertas entradas. Desafortunadamente, probar estos casos hace que JUnit finalice. Poner las llamadas al método en un nuevo Thread no parece ayudar, ya que System.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 talón por System.exit()?

La clase en cuestión es en realidad una herramienta de línea de comandos que intento probar dentro de JUnit. ¿Quizás JUnit simplemente no es la herramienta adecuada para el trabajo? Se agradecen las sugerencias de herramientas de prueba de regresión complementarias (preferiblemente algo que se integre bien con JUnit y EclEmma).

En efecto, Derkeiler.com sugiere:

• Por qué System.exit() ?

En lugar de terminar con System.exit(whateverValue), ¿por qué no lanzar una excepción no verificada? En el uso normal, se desplazará hasta el último receptor de 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 o cual prueba falló y pasará sin problemas a la siguiente.

• Prevenir System.exit() para salir realmente de la JVM:

Intente modificar TestCase para que se ejecute con un administrador de seguridad que evite llamar a System.exit, luego capture 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 Reglas del sistemauna colección de reglas JUnit(4.9+) para probar código que utiliza java.lang.System.
Esto fue mencionado inicialmente por Stefan Birkner en su respuesta de diciembre de 2011.

System.exit(…)

Utilizar el ExpectedSystemExit regla para comprobar 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 Sistema lambda tiene un método catchSystemExit.Con esta regla, puede probar el código, que llama a System.exit(…):

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


    @Test
    public void systemExitWithSelectedStatusCode0() {
        int status = SystemLambda.catchSystemExit(() -> {
            //the code under test, which calls System.exit(0);
        });

        assertEquals(0, status);
    }
}

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

public class 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é tal 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 poder burlarse o apagar el System.exit método, en una prueba JUnit.

Por ejemplo, usando JMockit podrías 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 (usando 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 usamos en nuestra base de código fue encapsular la llamada a System.exit() en un impl Runnable, que el método en cuestión usó de manera predeterminada. Para la prueba unitaria, configuramos un Runnable simulado 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()); 
}

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

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

Puede hacer 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 por casos de prueba, y la uso todo el tiempo cuando refactorizo ​​código heredado. Por lo general, no es donde voy a dejar las cosas, sino un paso intermedio para poner a prueba el código existente.

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);
}