Java: Jak przetestować metody wywołujące System.exit ()?

Mam kilka metod, które powinny wywoływać System.exit()określone dane wejściowe. Niestety testowanie tych przypadków powoduje zakończenie działania JUnit! Umieszczanie wywołań metod w nowym wątku nie wydaje się pomocne, ponieważ System.exit()kończy JVM, a nie tylko bieżący wątek. Czy istnieją jakieś wspólne wzorce radzenia sobie z tym? Na przykład, czy mogę zastąpić kod pośredniczącySystem.exit() ?

[EDYCJA] Ta klasa jest w rzeczywistości narzędziem wiersza poleceń, które próbuję przetestować w JUnit. Może JUnit po prostu nie jest odpowiednim narzędziem do pracy? Sugestie dotyczące uzupełniających narzędzi do testowania regresji są mile widziane (najlepiej coś, co dobrze integruje się z JUnit i EclEmma).

Rzeczywiście, Derkeiler.com sugeruje:

• Dlaczego System.exit()?

Zamiast kończyć z System.exit (whatValue), dlaczego nie zgłosić niesprawdzonego wyjątku? Podczas normalnego użytkowania będzie dryfował aż do ostatniego łapacza JVM i wyłączy skrypt (chyba że zdecydujesz się go złapać gdzieś po drodze, co może być kiedyś przydatne).

W scenariuszu JUnit zostanie przechwycony przez platformę JUnit, która zgłosi, że test taki i taki nie powiódł się i płynnie przechodzi do następnego.

• Zapobiegaj System.exit()faktycznemu wyjściu z JVM:

Spróbuj zmodyfikować TestCase, aby działał z menedżerem bezpieczeństwa, który uniemożliwia wywołanie System.exit, a następnie przechwyć wyjątek 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);
        }
    }
}

Aktualizacja z grudnia 2012 r .:

Will proponuje w komentarzach zastosowaniem zasady systemu , kolekcja JUnit (4.9+) zasady testowania kodu, który wykorzystuje java.lang.System.
Wspomniał o tym Stefan Birkner w swojej odpowiedzi z grudnia 2011 r.

System.exit(…)

Użyj ExpectedSystemExitreguły, aby sprawdzić, czy System.exit(…)to się nazywa.
Możesz także zweryfikować status wyjścia.

Na przykład:

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

Biblioteka System Rules ma regułę JUnit o nazwie ExpectedSystemExit. Dzięki tej regule możesz testować kod, który wywołuje 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);
    }
}

Pełne ujawnienie: jestem autorem tej biblioteki.

Co powiesz na wstrzyknięcie „ExitManager” do tych metod:

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

Kod produkcyjny używa ExitManagerImpl, a kod testowy używa ExitManagerMock i może sprawdzić, czy wywołano metodę exit () i za pomocą którego kodu wyjścia.

W rzeczywistości możesz wykpić lub wyeliminować System.exitmetodę w teście JUnit.

Na przykład, używając JMockit możesz pisać (są też inne sposoby):

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

EDYCJA: Test alternatywny (przy użyciu najnowszego interfejsu API JMockit), który nie pozwala na uruchomienie żadnego kodu po wywołaniu 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)");
}

Jedną sztuczką, której użyliśmy w naszej bazie kodu, było zakodowanie wywołania System.exit () w implementacji Runnable, której domyślnie używa ta metoda. Aby przeprowadzić test jednostkowy, ustawiliśmy inny fałszywy Runnable. Coś takiego:

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

... i metoda testowa JUnit ...

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

Utwórz próbną klasę, która otacza System.exit ()

Zgadzam się z Ericsem Chaefer . Ale jeśli użyjesz dobrego frameworka, takiego jak Mockito, wystarczy prosta konkretna klasa, nie potrzebujesz interfejsu i dwóch implementacji.

Zatrzymywanie wykonywania testu w System.exit ()

Problem:

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

Wyśmiewany Sytem.exit()nie zakończy wykonywania. Jest to złe, jeśli chcesz przetestować, który thing2nie jest wykonywany.

Rozwiązanie:

Powinieneś zmienić ten kod zgodnie z sugestią Martina :

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

I wykonaj System.exit(status)funkcję wywoływania. To zmusza cię do trzymania wszystkich swoich System.exit()w jednym miejscu w lub w pobliżu main(). Jest to czystsze niż dzwonienie System.exit()głęboko w logice.

Kod

Obwoluta:

public class SystemExit {

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

Główny:

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

Podobają mi się niektóre z udzielonych odpowiedzi, ale chciałem zademonstrować inną technikę, która jest często przydatna podczas testowania starszego kodu. Podany kod, taki jak:

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

Możesz dokonać bezpiecznego refaktoryzacji, aby utworzyć metodę, która otacza wywołanie System.exit:

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

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

Następnie możesz utworzyć fałszywy test, który zastąpi wyjście:

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

Jest to ogólna technika zastępowania zachowania przypadkami testowymi i używam jej cały czas podczas refaktoryzacji starszego kodu. Zwykle nie jest to miejsce, w którym zamierzam zostawić coś, ale pośredni krok do przetestowania istniejącego kodu.

Szybkie spojrzenie na interfejs API pokazuje, że System.exit może zgłosić wyjątek esp. jeśli sekuritymanager zabrania zamknięcia vm. Być może rozwiązaniem byłoby zainstalowanie takiego menedżera.

Możesz użyć java SecurityManager, aby zapobiec zamknięciu wirtualnej maszyny wirtualnej Java przez bieżący wątek. Poniższy kod powinien robić, co chcesz:

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

Aby odpowiedź VonC działała na JUnit 4, zmodyfikowałem kod w następujący sposób

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

Możesz przetestować System.exit (..) z zastąpieniem wystąpienia Runtime. Np. Z 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);
    }
}

Istnieją środowiska, w których zwracany kod wyjścia jest używany przez program wywołujący (na przykład ERRORLEVEL w MS Batch). Mamy testy wokół głównych metod, które robią to w naszym kodzie, i naszym podejściem było użycie podobnego zastąpienia SecurityManager, jak w innych testach tutaj.

Ostatniej nocy zebrałem mały plik JAR za pomocą adnotacji Junit @Rule, aby ukryć kod menedżera bezpieczeństwa, a także dodać oczekiwania na podstawie oczekiwanego kodu powrotu. http://code.google.com/p/junitsystemrules/

Większość rozwiązań będzie

• zakończ test (metoda, a nie cały przebieg), System.exit()wywoływany jest moment
• zignoruj ​​już zainstalowany SecurityManager
• Czasami są dość specyficzne dla środowiska testowego
• ograniczyć do użycia maksymalnie raz na przypadek testowy

Dlatego większość rozwiązań nie nadaje się do sytuacji, w których:

• Weryfikację skutków ubocznych należy przeprowadzić po wezwaniu do System.exit()
• Istniejący menedżer bezpieczeństwa jest częścią testów.
• Używana jest inna platforma testowa.
• Chcesz mieć wiele weryfikacji w jednym przypadku testowym. Może to nie być absolutnie zalecane, ale czasami może być bardzo wygodne, szczególnie w połączeniu z assertAll(), na przykład.

Nie byłem zadowolony z ograniczeń narzuconych przez istniejące rozwiązania przedstawione w innych odpowiedziach, dlatego sam coś wymyśliłem.

Następująca klasa udostępnia metodę, assertExits(int expectedStatus, Executable executable)która zapewnia, że System.exit()jest wywoływana z określoną statuswartością, a po niej można kontynuować test. Działa tak samo jak JUnit 5assertThrows . Szanuje również istniejącego menedżera bezpieczeństwa.

Pozostaje jeszcze jeden problem: gdy testowany kod instaluje nowego menedżera bezpieczeństwa, który całkowicie zastępuje menedżera bezpieczeństwa ustawionego przez test. Wszystkie inne SecurityManagerznane mi rozwiązania oparte są na tym samym problemie.

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

Możesz użyć tej klasy w następujący sposób:

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

W razie potrzeby kod można łatwo przenieść do JUnit 4, TestNG lub dowolnego innego środowiska. Jedynym elementem specyficznym dla frameworka jest test zakończony niepowodzeniem. Można to łatwo zmienić na coś niezależnego od frameworka (innego niż Junit 4 Rule

Jest miejsce na ulepszenia, na przykład przeciążenie assertExits()dostosowywanymi komunikatami.

Służy Runtime.exec(String command)do uruchamiania JVM w oddzielnym procesie.

Istnieje niewielki problem z SecurityManagerrozwiązaniem. Niektóre metody, takie jak JFrame.exitOnClosewywołanie SecurityManager.checkExit. W mojej aplikacji nie chciałem, aby to połączenie zakończyło się niepowodzeniem, więc skorzystałem

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

Wywołanie System.exit () jest złą praktyką, chyba że odbywa się to w main (). Metody te powinny zgłaszać wyjątek, który ostatecznie zostaje przechwycony przez twoją funkcję main (), która następnie wywołuje System.exit z odpowiednim kodem.