Java: come testare metodi che chiamano System.exit ()?

Ho alcuni metodi che dovrebbero chiamare System.exit()determinati input. Sfortunatamente, testare questi casi fa terminare JUnit! Inserire le chiamate di metodo in un nuovo thread non sembra aiutare, da alloraSystem.exit() termina la JVM, non solo il thread corrente. Ci sono schemi comuni per affrontarlo? Ad esempio, posso sostituire uno stub per System.exit()?

[EDIT] La classe in questione è in realtà uno strumento da riga di comando che sto tentando di testare all'interno di JUnit. Forse JUnit non è semplicemente lo strumento giusto per il lavoro? Suggerimenti per strumenti di test di regressione complementari sono ben accetti (preferibilmente qualcosa che si integra bene con JUnit ed EclEmma).

Infatti, Derkeiler.com suggerisce:

• Perché System.exit()?

Invece di terminare con System.exit (whateverValue), perché non generare un'eccezione non selezionata? Nell'uso normale si sposterà fino all'ultimo acchiappatore della JVM e chiuderà il tuo script (a meno che tu non decida di prenderlo da qualche parte lungo il percorso, che potrebbe essere utile un giorno).

Nello scenario JUnit verrà catturato dal framework JUnit, che riporterà che tale test fallito e si sposta senza intoppi al successivo.

• Impedisci System.exit()di uscire effettivamente dalla JVM:

Prova a modificare TestCase per l'esecuzione con un gestore della sicurezza che impedisce di chiamare System.exit, quindi intercetta 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);
        }
    }
}

Aggiornamento dicembre 2012:

Will propone nei commenti l' utilizzo di Regole di sistema , una raccolta di regole JUnit (4.9+) per testare il codice che utilizza java.lang.System.
Lo ha menzionato inizialmente Stefan Birkner nella sua risposta nel dicembre 2011.

System.exit(…)

Utilizzare la ExpectedSystemExitregola per verificare che System.exit(…)venga chiamato.
Puoi anche verificare lo stato di uscita.

Per esempio:

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 libreria System Lambda ha un metodo catchSystemExit. Con questa regola puoi testare il codice, che chiama System.exit (...):

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

Per Java da 5 a 7 la libreria Regole di sistema ha una regola JUnit chiamata ExpectedSystemExit. Con questa regola sei in grado di testare il codice, che chiama 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);
    }
}

Divulgazione completa: sono l'autore di entrambe le biblioteche.

Che ne dici di iniettare un "ExitManager" in questi metodi:

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

Il codice di produzione utilizza ExitManagerImpl e il codice di test utilizza ExitManagerMock e può verificare se è stato chiamato exit () e con quale codice di uscita.

In realtà è possibile prendere in giro o stub il System.exitmetodo, in un test JUnit.

Ad esempio, usando JMockit potresti scrivere (ci sono anche altri modi):

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

EDIT: test alternativo (utilizzando l'ultima API JMockit) che non consente l'esecuzione di alcun codice dopo una chiamata 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 trucco che abbiamo usato nella nostra base di codice era che la chiamata a System.exit () fosse incapsulata in un impl Runnable, che il metodo in questione usava di default. Per test unitario, abbiamo impostato un Runnable diverso. Qualcosa come questo:

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 il metodo di test JUnit ...

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

Crea una classe fittizia che avvolge System.exit ()

Sono d'accordo con EricSchaefer . Ma se usi un buon framework beffardo come Mockito , è sufficiente una semplice classe concreta, senza bisogno di un'interfaccia e due implementazioni.

Interruzione dell'esecuzione del test su System.exit ()

Problema:

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

Una derisione Sytem.exit()non termina l'esecuzione. Questo è male se vuoi provarlothing2 non venga eseguito.

Soluzione:

Dovresti refactificare questo codice come suggerito da Martin :

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

E fare System.exit(status)nella funzione di chiamata. Questo ti costringe ad avere tutti i tuoi System.exit()in un posto dentro o vicino main(). Questo è più pulito che chiamare in System.exit()profondità nella tua logica.

Codice

Wrapper:

public class SystemExit {

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

Principale:

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

Test:

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

Mi piacciono alcune delle risposte già fornite, ma volevo dimostrare una tecnica diversa che è spesso utile quando si verifica il codice legacy. Codice dato come:

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

È possibile eseguire un refactoring sicuro per creare un metodo che racchiuda la chiamata System.exit:

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

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

Quindi è possibile creare un falso per il test che ignora l'uscita:

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

Questa è una tecnica generica per sostituire il comportamento ai casi di test e lo uso sempre per il refactoring del codice legacy. Di solito non è dove lascerò qualcosa, ma un passaggio intermedio per mettere alla prova il codice esistente.

Un rapido sguardo all'API mostra che System.exit può generare un'eccezione esp. se un responsabile della sicurezza vieta l'arresto di VM. Forse una soluzione sarebbe installare un tale gestore.

È possibile utilizzare java SecurityManager per impedire al thread corrente di arrestare la VM Java. Il seguente codice dovrebbe fare quello che vuoi:

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

Per far funzionare la risposta di VonC su JUnit 4, ho modificato il codice come segue

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

È possibile testare System.exit (..) sostituendo l'istanza di Runtime. Ad esempio 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);
    }
}

Esistono ambienti in cui il programma di chiamata utilizza il codice di uscita restituito (come ERRORLEVEL in MS Batch). Abbiamo test sui metodi principali che eseguono questa operazione nel nostro codice e il nostro approccio è stato quello di utilizzare un override SecurityManager simile a quello utilizzato in altri test qui.

Ieri sera ho messo insieme un piccolo JAR usando le annotazioni di Junit @Rule per nascondere il codice del gestore della sicurezza, nonché aggiungere aspettative in base al codice di ritorno previsto. http://code.google.com/p/junitsystemrules/

La maggior parte delle soluzioni lo faranno

• termina il test (metodo, non l'intera corsa) il momento System.exit() viene chiamato
• ignora un già installato SecurityManager
• A volte è abbastanza specifico per un framework di test
• limitare l'uso massimo una volta per caso di test

Pertanto, la maggior parte delle soluzioni non è adatta a situazioni in cui:

• La verifica degli effetti collaterali deve essere eseguita dopo la chiamata a System.exit()
• Un gestore della sicurezza esistente fa parte del test.
• Viene utilizzato un diverso framework di test.
• Desideri avere più verifiche in un singolo caso di test. Questo può essere rigorosamente sconsigliato, ma a volte può essere molto conveniente, specialmente in combinazione con assertAll(), per esempio.

Non ero contento delle restrizioni imposte dalle soluzioni esistenti presentate nelle altre risposte, e quindi ho escogitato qualcosa da solo.

La seguente classe fornisce un metodo assertExits(int expectedStatus, Executable executable)che afferma di System.exit()essere chiamato con un statusvalore specificato e il test può continuare dopo di esso. Funziona allo stesso modo di JUnit 5assertThrows . Rispetta anche un gestore della sicurezza esistente.

Rimane un problema: quando il codice in prova installa un nuovo gestore della sicurezza che sostituisce completamente il gestore della sicurezza impostato dal test. Tutte le altre SecurityManagersoluzioni basate su me conosciute soffrono dello stesso 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;
        }
    }
}

Puoi usare la classe in questo modo:

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

Il codice può essere facilmente trasferito su JUnit 4, TestNG o qualsiasi altro framework, se necessario. L'unico elemento specifico del framework sta fallendo il test. Questo può essere facilmente modificato in qualcosa di indipendente dal framework (diverso da Junit 4 Rule

Vi sono margini di miglioramento, ad esempio il sovraccarico assertExits()di messaggi personalizzabili.

Utilizzare Runtime.exec(String command)per avviare JVM in un processo separato.

C'è un piccolo problema con la SecurityManagersoluzione. Alcuni metodi, come ad esempio JFrame.exitOnClose, chiamano anche SecurityManager.checkExit. Nella mia applicazione, non volevo che quella chiamata fallisse, quindi l'ho usata

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

Chiamare System.exit () è una cattiva pratica, a meno che non sia fatto all'interno di un main (). Questi metodi dovrebbero generare un'eccezione che, alla fine, viene catturata da main (), che quindi chiama System.exit con il codice appropriato.