Java: Como testar métodos que chamam System.exit ()?

Eu tenho alguns métodos que devem chamar System.exit()certas entradas. Infelizmente, testar esses casos faz com que o JUnit seja encerrado! Colocar as chamadas de método em um novo Thread não parece ajudar, pois System.exit()finaliza a JVM, não apenas o segmento atual. Existem padrões comuns para lidar com isso? Por exemplo, posso substituir um stub porSystem.exit() ?

[EDIT] A classe em questão é na verdade uma ferramenta de linha de comando que estou tentando testar dentro do JUnit. Talvez o JUnit simplesmente não seja a ferramenta certa para o trabalho? Sugestões para ferramentas complementares de teste de regressão são bem-vindas (de preferência algo que se integre bem ao JUnit e EclEmma).

De fato, Derkeiler.com sugere:

• Por quê System.exit() ?

Em vez de terminar com System.exit (WhateverValue), por que não lançar uma exceção desmarcada? Em uso normal, ele será direcionado para o apanhador de última hora da JVM e encerrará seu script (a menos que você decida capturá-lo em algum lugar ao longo do caminho, o que pode ser útil algum dia).

No cenário JUnit, ele será capturado pela estrutura JUnit, que relatará que esse teste falhou e se move suavemente para o próximo.

• Evite System.exit()realmente sair da JVM:

Tente modificar o TestCase para executar com um gerenciador de segurança que evite chamar System.exit e, em seguida, pegue a 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);
        }
    }
}

Atualização em dezembro de 2012:

Will propõe nos comentários, usando as Regras do sistema , uma coleção de regras JUnit (4.9+) para testar o código usado java.lang.System.
Isso foi mencionado inicialmente por Stefan Birkner em sua resposta em dezembro de 2011.

System.exit(…)

Use a ExpectedSystemExitregra para verificar se isso System.exit(…)é chamado.
Você também pode verificar o status da saída.

Por exemplo:

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

A biblioteca System Rules possui uma regra JUnit chamada ExpectedSystemExit. Com esta regra, você pode testar o código, que chama 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);
    }
}

Divulgação completa: sou o autor dessa biblioteca.

Que tal injetar um "ExitManager" nesses 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
    }
}

O código de produção usa o ExitManagerImpl e o código de teste usa ExitManagerMock e pode verificar se exit () foi chamado e com qual código de saída.

Na verdade, você pode zombar ou apagar oSystem.exit método em um teste JUnit.

Por exemplo, usando o JMockit, você pode escrever (existem outras maneiras também):

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

EDIT: Teste alternativo (usando a API JMockit mais recente) que não permite que nenhum código seja executado após uma chamada para 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)");
}

Um truque que usamos em nossa base de código foi fazer com que a chamada para System.exit () fosse encapsulada em um impl Runnable, que o método em questão usou por padrão. Para teste de unidade, definimos um Runnable simulado diferente. Algo assim:

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

... e o método de teste JUnit ...

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

Crie uma classe com capacidade de simulação que envolva System.exit ()

Eu concordo com EricSchaefer . Mas se você usar uma boa estrutura de zombaria como o Mockito , basta uma classe simples e concreta, sem necessidade de uma interface e duas implementações.

Parando a execução de teste em System.exit ()

Problema:

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

Uma zombaria Sytem.exit()não terminará a execução. Isso é ruim se você quiser testar issothing2 se não é executado.

Solução:

Você deve refatorar esse código conforme sugerido por martin :

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

E faça System.exit(status)na função de chamada. Isso força você a ter todos os seus System.exit()s em um só lugar ou perto dele main(). Isso é mais limpo do que chamarSystem.exit() profundamente dentro de sua lógica.

Código

Embrulho:

public class SystemExit {

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

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

Teste:

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

Gosto de algumas das respostas já dadas, mas queria demonstrar uma técnica diferente que geralmente é útil ao testar o código legado. Código fornecido como:

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

Você pode fazer uma refatoração segura para criar um método que agrupe a chamada System.exit:

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

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

Em seguida, você pode criar um falso para o seu teste que substitui a saída:

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

Essa é uma técnica genérica para substituir o comportamento por casos de teste, e eu a uso o tempo todo ao refatorar o código legado. Geralmente não é onde eu vou deixar as coisas, mas uma etapa intermediária para testar o código existente.

Uma rápida olhada na API, mostra que o System.exit pode gerar uma exceção esp. se um gerenciador de segurança proíbe o desligamento da VM. Talvez uma solução seria instalar um gerente desse tipo.

Você pode usar o java SecurityManager para impedir que o encadeamento atual desligue a Java VM. O código a seguir deve fazer o que você deseja:

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 a resposta do VonC seja executada no JUnit 4, modifiquei o código da seguinte maneira

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

Você pode testar System.exit (..) substituindo a instância do Runtime. Por exemplo, com 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);
    }
}

Existem ambientes em que o código de saída retornado é usado pelo programa de chamada (como ERRORLEVEL no MS Batch). Temos testes em torno dos métodos principais que fazem isso em nosso código, e nossa abordagem foi usar uma substituição semelhante do SecurityManager, como usado em outros testes aqui.

Ontem à noite, montei um pequeno JAR usando as anotações do Junit @Rule para ocultar o código do gerenciador de segurança, além de adicionar expectativas com base no código de retorno esperado. http://code.google.com/p/junitsystemrules/

A maioria das soluções

• finalizar o teste (método, não a execução inteira), o momento System.exit()é chamado
• ignore um já instalado SecurityManager
• Às vezes, seja bastante específico para uma estrutura de teste
• restrito a ser usado no máximo uma vez por caso de teste

Portanto, a maioria das soluções não é adequada para situações em que:

• A verificação dos efeitos colaterais deve ser realizada após a chamada para System.exit()
• Um gerenciador de segurança existente faz parte do teste.
• Uma estrutura de teste diferente é usada.
• Você deseja ter várias verificações em um único caso de teste. Isso pode não ser estritamente recomendado, mas pode ser muito conveniente às vezes, especialmente em combinação com assertAll(), por exemplo.

Não fiquei satisfeito com as restrições impostas pelas soluções existentes apresentadas nas outras respostas e, portanto, criei algo sozinho.

A classe a seguir fornece um método assertExits(int expectedStatus, Executable executable)que afirma que System.exit()é chamado com um statusvalor especificado e o teste pode continuar após ele. Funciona da mesma maneira que o JUnit 5 assertThrows. Ele também respeita um gerenciador de segurança existente.

Há um problema restante: quando o código em teste instala um novo gerenciador de segurança que substitui completamente o gerenciador de segurança definido pelo teste. Todas as outras SecurityManagersoluções baseadas em mim conhecidas sofrem o mesmo 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;
        }
    }
}

Você pode usar a classe assim:

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

O código pode ser facilmente portado para JUnit 4, TestNG ou qualquer outra estrutura, se necessário. O único elemento específico da estrutura está falhando no teste. Isso pode ser facilmente alterado para algo independente de estrutura (exceto um Junit 4 Rule

Há espaço para melhorias, por exemplo, sobrecarregando assertExits()com mensagens personalizáveis.

Use Runtime.exec(String command)para iniciar a JVM em um processo separado.

Há um pequeno problema com a SecurityManagersolução. Alguns métodos, como JFrame.exitOnClose, também chamam SecurityManager.checkExit. No meu aplicativo, eu não queria que a chamada falhasse, então usei

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

Chamar System.exit () é uma prática ruim, a menos que seja feita dentro de um main (). Esses métodos devem gerar uma exceção que, em última análise, é capturada pelo seu main (), que chama System.exit com o código apropriado.