Java: Як перевірити методи, які викликають System.exit ()?

У мене є кілька методів, які потребують System.exit()певних входів. На жаль, тестування цих випадків призводить до припинення роботи JUnit! Введення викликів методу в нову тему, здається, не допоможе, оскільки System.exit()припиняє JVM, а не лише поточну нитку. Чи є загальні закономірності для вирішення цього питання? Наприклад, чи можу я замінити заглушку System.exit()?

[EDIT] Клас, про який йде мова, насправді є інструментом командного рядка, який я намагаюся перевірити в JUnit. Може бути, JUnit просто не є правильним інструментом для роботи? Пропозиції щодо додаткових інструментів тестування регресії вітаються (бажано, що добре поєднується з JUnit та EclEmma).

Дійсно, Derkeiler.com пропонує:

• Чому System.exit()?

Замість того, щоб припиняти використання System.exit (незалежно від Valalue), чому б не кинути неперевірений виняток? При звичайному використанні він винесе весь шлях до останнього виловника JVM і закриє ваш скрипт (якщо ви не вирішите зловити його десь на шляху, що може бути корисним колись).

У сценарії JUnit він потрапить у рамку JUnit, яка повідомить, що такий і такий тест виявився невдалим і плавно рухається до наступного.

• Запобігайте System.exit()фактичному виходу з СВМ:

Спробуйте змінити TestCase для запуску з диспетчером безпеки, який запобігає виклику System.exit, а потім зафіксуйте 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(…)

Використовуйте ExpectedSystemExitправило, щоб перевірити, що System.exit(…)викликається.
Ви можете також підтвердити статус виходу.

Наприклад:

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

Бібліотечні правила системи мають правило JUnit під назвою ExpectedSystemExit. За допомогою цього правила ви можете перевірити код, який викликає 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);
    }
}

Повне розкриття: Я автор цієї бібліотеки.

Як щодо введення "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 () і з яким кодом виходу.

Насправді ви можете знущатись або стримувати System.exitметод у тесті JUnit.

Наприклад, за допомогою JMockit можна писати (є й інші способи):

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

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

Один трюк, який ми використовували в нашій кодовій базі, полягав у тому, щоб виклик System.exit () був інкапсульований у імпульсі Runnable, який за типовим методом використовувався. Для тестування блоку ми встановили інший макет 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()); 
}

Створіть макетний клас, який обгортає System.exit ()

Я згоден з Еріком Шефер . Але якщо ви використовуєте хороший глузливий фреймворк, як Mockito, достатньо простого конкретного класу, не потрібно інтерфейсу та двох реалізацій.

Припинення виконання тесту на System.exit ()

Проблема:

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

Знущання Sytem.exit()не завершить виконання. Це погано, якщо ви хочете перевірити, що thing2не виконується.

Рішення:

Вам слід переробити цей код, як запропонував martin :

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

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

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

Це загальна методика заміни поведінки для тестових випадків, і я її використовую весь час, коли рефакторинг застарілого коду. Це зазвичай не те, де я збираюся залишити річ, а проміжний крок, щоб отримати існуючий код на тестування.

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

Ви можете використовувати java SecurityManager, щоб запобігти відключенню поточного потоку Java VM. Наступний код повинен робити те, що ви хочете:

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

Для відповіді 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);
}

Ви можете перевірити 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);
    }
}

Існують середовища, де повернений код виходу використовується програмою, що викликає (наприклад, ERRORLEVEL в MS Batch). У нас є тести навколо основних методів, які роблять це в нашому коді, і наш підхід полягав у використанні аналогічного переопрацювання SecurityManager, що використовується в інших тестах тут.

Минулої ночі я зібрав невеликий JAR за допомогою анотацій Junit @Rule, щоб приховати код менеджера безпеки, а також додати очікування на основі очікуваного коду повернення. http://code.google.com/p/junitsystemrules/

Більшість рішень буде

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

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

• Перевірка побічних ефектів повинна здійснюватися після дзвінка на System.exit()
• Існуючий менеджер безпеки є частиною тестування.
• Використовується інша рамка тесту.
• Ви хочете мати кілька перевірок в одному тестовому випадку. Це може бути категорично не рекомендується, але може бути дуже зручним часом, особливо в поєднанні assertAll(), наприклад.

Я не був задоволений обмеженнями, накладеними існуючими рішеннями, представленими в інших відповідях, і, таким чином, придумав щось самостійно.

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

Залишилася одна проблема: коли тестовий код встановлює новий менеджер захисту, який повністю замінює диспетчер безпеки, встановлений тестом. Усі інші 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 або будь-який інший фреймворк, якщо це необхідно. Єдиний елемент, що стосується рамки, - це невдача тесту. Це можна легко змінити на щось незалежне від рамки (крім Junit 4 Rule

Є можливість вдосконалення, наприклад, перевантаження за assertExits()допомогою налаштованих повідомлень.

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

З SecurityManagerрішенням є незначна проблема . Деякі методи, наприклад JFrame.exitOnClose, також вимагають SecurityManager.checkExit. У своїй програмі я не хотів, щоб цей дзвінок закінчувався, тому я використовував

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

Виклик System.exit () є поганою практикою, якщо це не робиться всередині main (). Ці методи повинні бути викидом, який, зрештою, потрапляє у ваш головний (), який потім викликає System.exit з відповідним кодом.