Wie testet man Methoden, die System.exit() aufrufen?

Ich habe ein paar Methoden, die aufrufen sollten System.exit() bei bestimmten Eingängen. Leider führt das Testen dieser Fälle dazu, dass JUnit beendet wird! Die Methodenaufrufe in einen neuen Thread zu packen scheint da nicht zu helfen System.exit() beendet die JVM, nicht nur den aktuellen Thread. Gibt es gängige Muster für den Umgang damit? Kann ich zum Beispiel einen Stub ersetzen System.exit()?

Die fragliche Klasse ist eigentlich ein Befehlszeilentool, das ich in JUnit zu testen versuche. 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, Derkeiler.com schlägt vor:

• Warum System.exit() ?

Anstatt mit System.exit(whateverValue) zu enden, warum nicht eine ungeprüfte Ausnahme auslösen? Bei normaler Verwendung driftet es bis zum letzten Fang der JVM und beendet Ihr Skript (es sei denn, Sie entscheiden sich, es irgendwo auf dem Weg abzufangen, was eines Tages nützlich sein könnte).

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

• Verhindern System.exit() um die JVM tatsächlich zu beenden:

Versuchen Sie, den Testfall 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 die Verwendung vor Systemregelneine Sammlung von JUnit(4.9+)-Regeln zum Testen von Code, der verwendet java.lang.System.
Dies wurde ursprünglich von erwähnt Stefan Birkner in seiner Antwort im Dezember 2011.

System.exit(…)

Verwenden Sie die ExpectedSystemExit Regel, um das zu überprüfen System.exit(…) wird genannt.
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-Lambda hat Methode catchSystemExit.Mit dieser Regel können Sie Code testen, der System.exit(…) aufruft:

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

Für Java 5 bis 7 die Bibliothek Systemregeln hat eine JUnit-Regel namens ExpectedSystemExit. Mit dieser Regel können Sie Code testen, der System.exit(…) aufruft:

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

Vollständige Offenlegung: Ich bin der Autor beider Bibliotheken.

Wie wäre es, einen “ExitManager” in diese Methoden einzufügen:

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 den ExitManagerImpl und der Testcode verwendet ExitManagerMock und kann überprüfen, ob exit() aufgerufen wurde und mit welchem ​​Exit-Code.

Du eigentlich dürfen verspotten oder Stub aus dem System.exit Methode in einem JUnit-Test.

Zum Beispiel mit JMockit du könntest schreiben (es geht auch anders):

@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 kein Code nach einem Aufruf von ausgeführt werden kann 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)");
}

Ein Trick, den wir in unserer Codebasis verwendet haben, bestand darin, den Aufruf von System.exit() in ein ausführbares Impl zu kapseln, das die betreffende Methode standardmäßig verwendet. Für den Komponententest haben wir ein anderes Schein-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()); 
}

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 für Ihren Test eine Fälschung erstellen, die den Ausgang ü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 zum Ersetzen von Verhalten für Testfälle, und ich verwende sie ständig beim Refactoring von Legacy-Code. Es ist normalerweise nicht, wo ich das Ding verlassen werde, sondern ein Zwischenschritt, um den vorhandenen Code zu testen.

Damit die Antwort von VonC 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);
}