Java: как проверить методы, вызывающие System.exit ()?

Беглый взгляд на api показывает, что System.exit может генерировать исключение esp. если менеджер безопасности запрещает выключение vm. Может решением было бы установить такой менеджер.

Действительно, Derkeiler.com предлагает:

• Почему System.exit()?

Instead of terminating with System.exit(whateverValue), why not throw an unchecked exception? In normal use it will drift all the way out to the JVM's last-ditch catcher and shut your script down (unless you decide to catch it somewhere along the way, which might be useful someday).

In the JUnit scenario it will be caught by the JUnit framework, which will report that such-and-such test failed and move smoothly along to the next.

• Предотвратить фактический выход System.exit() из JVM:

Try modifying the TestCase to run with a security manager that prevents calling System.exit, then catch the 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);
        }
    }
}

Обновление за декабрь 2012 г .:

Воля предлагает в комментариях с использованием Системные правила, набора правил JUnit (4.9+) для тестирования кода, который использует java.lang.System.
Первоначально об этом упоминал Стефан Биркнер в его ответ в декабре 2011 года.

System.exit(…)

Use the ExpectedSystemExit rule to verify that System.exit(…) is called.
You could verify the exit status, too.

Например:

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

Вызов System.exit () - плохая практика, если только это не делается внутри main (). Эти методы должны генерировать исключение, которое, в конечном итоге, перехватывается вашим main (), который затем вызывает System.exit с соответствующим кодом.

Один трюк, который мы использовали в нашей базе кода, заключался в том, чтобы вызов System.exit () был инкапсулирован в Runnable impl, который рассматриваемый метод использовал по умолчанию. Для модульного тестирования мы установили другой макет Runnable. Что-то вроде этого:

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

... и метод тестирования JUnit ...

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

Вы можете использовать java SecurityManager, чтобы предотвратить завершение работы виртуальной машины Java текущим потоком. Следующий код должен делать то, что вы хотите:

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

Как насчет внедрения ExitManager в эти методы:

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

Рабочий код использует ExitManagerImpl, а тестовый код использует ExitManagerMock и может проверить, был ли вызван exit () и с каким кодом выхода.

Мне нравятся некоторые из уже приведенных ответов, но я хотел продемонстрировать другую технику, которая часто бывает полезна при тестировании унаследованного кода. Данный код вроде:

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

Вы можете выполнить безопасный рефакторинг, чтобы создать метод, который обертывает вызов System.exit:

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

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

Затем вы можете создать подделку для своего теста, которая отменяет выход:

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

Это общий метод замены поведения тестовыми примерами, и я постоянно использую его при рефакторинге устаревшего кода. Обычно это не то место, где я собираюсь оставить это, а промежуточный шаг для тестирования существующего кода.

Вы фактически может имитируете или игнорируете метод System.exit в тесте JUnit.

Например, используя JMockit, вы можете написать (есть и другие способы):

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

Обновлено: альтернативный тест (с использованием последней версии JMockit API), который не позволяет запускать какой-либо код после вызова 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)");
}

Чтобы ответ VonC работал на JUnit 4, я изменил код следующим образом

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

Есть среды, в которых возвращаемый код выхода используется вызывающей программой (например, ERRORLEVEL в MS Batch). У нас есть тесты для основных методов, которые делают это в нашем коде, и наш подход заключался в использовании аналогичного переопределения SecurityManager, которое используется в других тестах здесь.

Вчера вечером я собрал небольшой JAR, используя аннотации Junit @Rule, чтобы скрыть код диспетчера безопасности, а также добавить ожидания на основе ожидаемого кода возврата. http://code.google.com/p/junitsystemrules/

Используйте Runtime.exec(String command) для запуска JVM в отдельном процессе.

В библиотеке Системная лямбда есть метод catchSystemExit. С помощью этого правила вы можете тестировать код, который вызывает System.exit (...):

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

Для Java 5–7 в библиотеке Системные правила есть правило JUnit под названием ExpectedSystemExit. С помощью этого правила вы можете протестировать код, который вызывает System.exit (...):

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

Полное раскрытие: я являюсь автором обеих библиотек.

Создайте фиктивный класс, который обертывает System.exit ()

Я согласен с Эрик Шефер. Но если вы используете хороший фреймворк для имитации, такой как Mockito, достаточно простого конкретного класса, нет необходимости в интерфейсе и двух реализациях.

Остановка выполнения теста на System.exit ()

Проблема:

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

Поддельный Sytem.exit() не прекращает выполнение. Это плохо, если вы хотите проверить, что thing2 не выполняется.

Решение:

Вы должны реорганизовать этот код, как это предлагает Мартин:

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

И сделайте System.exit(status) в вызывающей функции. Это заставляет вас иметь все ваши System.exit() в одном месте в main() или рядом с ним. Это чище, чем вызов System.exit() глубоко внутри вашей логики.

Код

Обертка:

public class SystemExit {

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

Основной:

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

Тестовое задание:

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

Есть небольшая проблема с решением SecurityManager. Некоторые методы, такие как JFrame.exitOnClose, также вызывают SecurityManager.checkExit. В моем приложении я не хотел, чтобы этот вызов завершился сбоем, поэтому я использовал

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

Вы можете протестировать System.exit (..) с заменой экземпляра Runtime. Например. с 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);
    }
}

Большинство решений будут

• завершить тест (метод, а не весь прогон) в момент вызова System.exit()
• игнорировать уже установленный SecurityManager
• Иногда быть довольно специфичным для тестовой среды
• ограничить использование не более одного раза в тестовом примере

Таким образом, большинство решений не подходят для ситуаций, когда:

• Проверка наличия побочных эффектов проводится после звонка в System.exit().
• Существующий менеджер безопасности является частью тестирования.
• Используется другая среда тестирования.
• Вы хотите иметь несколько проверок в одном тестовом примере. Это может быть строго не рекомендовано, но иногда может быть очень удобным, особенно в сочетании, например, с assertAll().

Я не был доволен ограничениями, налагаемыми существующими решениями, представленными в других ответах, и поэтому придумал что-то самостоятельно.

Следующий класс предоставляет метод assertExits(int expectedStatus, Executable executable), который утверждает, что System.exit() вызывается с указанным значением status, и после этого тест может продолжаться. Он работает так же, как JUnit 5 assertThrows. Он также уважает существующего менеджера по безопасности.

Остается одна проблема: когда тестируемый код устанавливает новый диспетчер безопасности, который полностью заменяет диспетчер безопасности, установленный тестом. Все остальные известные мне решения на основе SecurityManager страдают той же проблемой.

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

Вы можете использовать этот класс так:

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

При необходимости код можно легко перенести на JUnit 4, TestNG или любую другую платформу. Единственный элемент, зависящий от фреймворка, не проходит тест. Это можно легко изменить на что-то независимое от фреймворка (кроме Юнит 4Rule

Есть возможности для улучшения, например, перегрузка assertExits() настраиваемыми сообщениями.

Системные заглушки - https://github.com/webcompere/system-stubs - тоже могут решить эту проблему. Он использует синтаксис System Lambda для обертывания кода, который знать будет выполнять System.exit, но это может привести к странным эффектам, когда другой код неожиданно завершает работу.

С помощью плагина JUnit 5 мы можем гарантировать, что любой выход будет преобразован в исключение:

@ExtendWith(SystemStubsExtension.class)
class SystemExitUseCase {
    // the presence of this in the test means System.exit becomes an exception
    @SystemStub
    private SystemExit systemExit;

    @Test
    void doSomethingThatAccidentallyCallsSystemExit() {
        // this test would have stopped the JVM, now it ends in `AbortExecutionException`
        // System.exit(1);
    }

    @Test
    void canCatchSystemExit() {
        assertThatThrownBy(() -> System.exit(1))
            .isInstanceOf(AbortExecutionException.class);

        assertThat(systemExit.getExitCode()).isEqualTo(1);
    }
}

В качестве альтернативы также можно использовать статический метод, подобный утверждению:

assertThat(catchSystemExit(() -> {
   //the code under test
   System.exit(123);
})).isEqualTo(123);