Java: Wie teste ich Methoden, die System.exit () aufrufen?

Ich habe ein paar Methoden, die aufrufen sollten System.exit() bestimmte Eingaben . Leider führt das Testen dieser Fälle dazu, dass JUnit beendet wird! Das Einfügen der Methodenaufrufe in einen neuen Thread scheint nicht zu helfen, da System.exit()die JVM beendet wird, nicht nur der aktuelle Thread. Gibt es gemeinsame Muster, um damit umzugehen? Kann ich zum Beispiel einen Stub ersetzen System.exit()?

[EDIT] Die betreffende Klasse ist eigentlich ein Befehlszeilentool, das ich in JUnit testen möchte. Vielleicht ist JUnit einfach nicht das richtige Werkzeug für den Job? Vorschläge für ergänzende Regressionstest-Tools sind willkommen (vorzugsweise etwas, das sich gut in JUnit und EclEmma integrieren lässt).

In der Tat schlägt Derkeiler.com vor:

• Warum System.exit()?

Warum nicht eine ungeprüfte Ausnahme auslösen, anstatt mit System.exit (WhateverValue) zu beenden? Bei normaler Verwendung driftet es bis zum letzten Grabenfänger der JVM und fährt Ihr Skript herunter (es sei denn, Sie möchten es irgendwo auf dem Weg abfangen, was eines Tages nützlich sein könnte).

Im JUnit-Szenario wird es vom JUnit-Framework erfasst, das meldet, dass der eine oder andere Test fehlgeschlagen ist, und reibungslos zum nächsten übergeht.

• Verhindern Sie System.exit(), dass die JVM tatsächlich beendet wird:

Versuchen Sie, den TestCase so zu ändern, dass er mit einem Sicherheitsmanager ausgeführt wird, der das Aufrufen von System.exit verhindert, und fangen Sie dann die SecurityException ab.

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

Update Dezember 2012:

Will schlägt in den Kommentaren unter Verwendung von Systemregeln eine Sammlung von JUnit-Regeln (4.9+) zum Testen von Code vor, die verwendet werden java.lang.System.
Dies wurde ursprünglich von Stefan Birkner in seiner Antwort im Dezember 2011 erwähnt.

System.exit(…)

Verwenden Sie die ExpectedSystemExitRegel, um zu überprüfen, ob sie System.exit(…)aufgerufen wird.
Sie können auch den Exit-Status überprüfen.

Zum Beispiel:

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

Die Bibliothek System Rules verfügt über eine JUnit-Regel namens ExpectedSystemExit. Mit dieser Regel können Sie Code testen, der System.exit (...) aufruft:

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

Vollständige Offenlegung: Ich bin der Autor dieser Bibliothek.

Wie wäre es mit einem "ExitManager" in diese Methoden:

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

Der Produktionscode verwendet ExitManagerImpl und der Testcode verwendet ExitManagerMock und kann überprüfen, ob exit () aufgerufen wurde und mit welchem ​​Exit-Code.

Sie können die System.exitMethode in einem JUnit-Test tatsächlich verspotten oder auslöschen.

Mit JMockit können Sie beispielsweise schreiben (es gibt auch andere Möglichkeiten):

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

BEARBEITEN: Alternativer Test (unter Verwendung der neuesten JMockit-API), bei dem nach einem Aufruf von System.exit(n): kein Code ausgeführt werden kann :

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

Ein Trick, den wir in unserer Codebasis verwendet haben, bestand darin, den Aufruf von System.exit () in ein Runnable-Impl zu kapseln, das die betreffende Methode standardmäßig verwendet. Zum Unit-Test haben wir ein anderes Mock-Runnable festgelegt. Etwas wie das:

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

... und die JUnit-Testmethode ...

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

Erstellen Sie eine verspottbare Klasse, die System.exit () umschließt.

Ich stimme EricSchaefer zu . Aber wenn Sie ein gutes Spott-Framework wie Mockito verwenden eine einfache konkrete Klasse aus, ohne dass eine Schnittstelle und zwei Implementierungen erforderlich sind.

Beenden der Testausführung auf System.exit ()

Problem:

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

Ein Verspotteter Sytem.exit()beendet die Ausführung nicht. Das ist schlecht, wenn Sie das testen möchtenthing2 nicht ausgeführt wird.

Lösung:

Sie sollten diesen Code wie von Martin vorgeschlagen umgestalten :

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

Und zwar System.exit(status)in der aufrufenden Funktion. Dies zwingt Sie dazu, alle Ihre System.exit()s an einem Ort in oder in der Nähe zu haben main(). Dies ist sauberer als System.exit()tief in Ihrer Logik zu rufen .

Code

Verpackung:

public class SystemExit {

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

Main:

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

Prüfung:

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

Ich mag einige der bereits gegebenen Antworten, aber ich wollte eine andere Technik demonstrieren, die oft nützlich ist, wenn Legacy-Code getestet wird. Gegebener Code wie:

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

Sie können ein sicheres Refactoring durchführen, um eine Methode zu erstellen, die den System.exit-Aufruf umschließt:

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

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

Dann können Sie eine Fälschung für Ihren Test erstellen, die den Exit überschreibt:

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

Dies ist eine generische Technik, um Testfälle durch Verhalten zu ersetzen, und ich verwende sie ständig, wenn ich alten Code umgestalte. Es ist normalerweise nicht der Ort, an dem ich das Ding verlassen werde, sondern ein Zwischenschritt, um den vorhandenen Code zu testen.

Ein kurzer Blick auf die API zeigt, dass System.exit eine Ausnahme auslösen kann, insb. wenn ein Sicherheitsmanager das Herunterfahren der VM verbietet. Vielleicht wäre eine Lösung, einen solchen Manager zu installieren.

Mit dem Java SecurityManager können Sie verhindern, dass der aktuelle Thread die Java-VM herunterfährt. Der folgende Code sollte tun, was Sie wollen:

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

Damit VonCs Antwort auf JUnit 4 ausgeführt werden kann, habe ich den Code wie folgt geändert

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

Sie können System.exit (..) testen, indem Sie die Runtime-Instanz ersetzen. ZB mit 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);
    }
}

Es gibt Umgebungen, in denen der zurückgegebene Exit-Code vom aufrufenden Programm verwendet wird (z. B. ERRORLEVEL in MS Batch). Wir haben Tests zu den wichtigsten Methoden, die dies in unserem Code tun, und unser Ansatz bestand darin, eine ähnliche SecurityManager-Überschreibung zu verwenden, wie sie in anderen Tests hier verwendet wurde.

Letzte Nacht habe ich eine kleine JAR mit Junit @ Rule-Annotationen zusammengestellt, um den Security Manager-Code auszublenden und Erwartungen basierend auf dem erwarteten Rückkehrcode hinzuzufügen. http://code.google.com/p/junitsystemrules/

Die meisten Lösungen werden

• Beenden Sie den Test (Methode, nicht den gesamten Lauf), sobald der Moment System.exit()aufgerufen wird
• ignoriere eine bereits installierte SecurityManager
• Seien Sie manchmal sehr spezifisch für ein Test-Framework
• Beschränken Sie die Verwendung auf maximal einmal pro Testfall

Daher sind die meisten Lösungen nicht für Situationen geeignet, in denen:

• Die Überprüfung der Nebenwirkungen ist nach dem Anruf bei durchzuführen System.exit()
• Ein vorhandener Sicherheitsmanager ist Teil des Tests.
• Ein anderes Testframework wird verwendet.
• Sie möchten mehrere Überprüfungen in einem einzigen Testfall durchführen. Dies kann strengstens nicht empfohlen werden, kann aber manchmal sehr praktisch sein, insbesondere in Kombination mit assertAll()beispielsweise.

Ich war mit den Einschränkungen, die durch die vorhandenen Lösungen in den anderen Antworten auferlegt wurden, nicht zufrieden und kam daher auf meine eigene Idee.

Die folgende Klasse stellt eine Methode bereit, assertExits(int expectedStatus, Executable executable)die bestätigt, dass System.exit()sie mit einem angegebenen statusWert aufgerufen wird, und der Test kann danach fortgesetzt werden. Es funktioniert genauso wie JUnit 5assertThrows . Es respektiert auch einen vorhandenen Sicherheitsmanager.

Es gibt noch ein Problem: Wenn der zu testende Code einen neuen Sicherheitsmanager installiert, der den durch den Test festgelegten Sicherheitsmanager vollständig ersetzt. Alle anderen SecurityManagermir bekannten Lösungen haben das gleiche Problem.

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

Sie können die Klasse folgendermaßen verwenden:

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

Der Code kann bei Bedarf problemlos auf JUnit 4, TestNG oder ein anderes Framework portiert werden. Das einzige Framework-spezifische Element besteht darin, den Test nicht zu bestehen. Dies kann leicht in etwas Framework-unabhängiges geändert werden (außer einem Junit 4) Rule

Es gibt Raum für Verbesserungen, zum Beispiel das Überladen assertExits()mit anpassbaren Nachrichten.

Verwenden Sie Runtime.exec(String command)diese Option, um JVM in einem separaten Prozess zu starten.

Es gibt ein kleines Problem mit der SecurityManagerLösung. Einige Methoden, wie z. B. JFrame.exitOnClosecall SecurityManager.checkExit. In meiner Anwendung wollte ich nicht, dass dieser Aufruf fehlschlägt, also habe ich verwendet

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

Das Aufrufen von System.exit () ist eine schlechte Vorgehensweise, es sei denn, es erfolgt in einem main (). Diese Methoden sollten eine Ausnahme auslösen, die letztendlich von Ihrem main () abgefangen wird, der dann System.exit mit dem entsprechenden Code aufruft.