Java: Làm thế nào để kiểm tra các phương thức gọi System.exit ()?

Tôi đã có một vài phương pháp nên gọi System.exit()một số đầu vào nhất định. Thật không may, kiểm tra những trường hợp này khiến JUnit chấm dứt! Việc đặt các cuộc gọi phương thức trong một System.exit()luồng mới dường như không có ích gì, vì chấm dứt JVM, không chỉ là luồng hiện tại. Có bất kỳ mô hình phổ biến để đối phó với điều này? Ví dụ, tôi có thể đăng ký sơ khai System.exit()không?

[EDIT] Lớp trong câu hỏi thực sự là một công cụ dòng lệnh mà tôi đang cố kiểm tra bên trong JUnit. Có lẽ JUnit đơn giản không phải là công cụ phù hợp cho công việc? Đề xuất cho các công cụ kiểm tra hồi quy bổ sung được hoan nghênh (tốt nhất là một cái gì đó tích hợp tốt với JUnit và EclEmma).

Thật vậy, Derkeiler.com gợi ý:

• Tại sao System.exit()?

Thay vì chấm dứt với System.exit (anythingValue), tại sao không ném một ngoại lệ không được kiểm soát? Trong sử dụng bình thường, nó sẽ trôi dạt đến công cụ bắt cuối cùng của JVM và tắt tập lệnh của bạn (trừ khi bạn quyết định bắt nó ở đâu đó trên đường đi, điều này có thể hữu ích vào một ngày nào đó).

Trong kịch bản JUnit, khung công tác JUnit sẽ bắt gặp, nó sẽ báo cáo rằng thử nghiệm tương tự như vậy đã thất bại và chuyển trơn tru sang kế tiếp.

• Ngăn chặn System.exit()để thực sự thoát JVM:

Hãy thử sửa đổi TestCase để chạy với trình quản lý bảo mật ngăn việc gọi System.exit, sau đó bắt 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);
        }
    }
}

Cập nhật tháng 12 năm 2012:

Sẽ đề xuất trong các nhận xét bằng cách sử dụng Quy tắc hệ thống , một tập hợp các quy tắc JUnit (4.9+) để kiểm tra mã sử dụng java.lang.System.
Điều này ban đầu được đề cập bởi Stefan Birkner trong câu trả lời của ông vào tháng 12 năm 2011.

System.exit(…)

Sử dụng ExpectedSystemExitquy tắc để xác minh rằng System.exit(…)được gọi.
Bạn cũng có thể xác minh trạng thái thoát.

Ví dụ:

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

Các quy tắc hệ thống thư viện có một quy tắc JUnit được gọi là ExpectedSystemExit. Với quy tắc này, bạn có thể kiểm tra mã, gọi 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);
    }
}

Tiết lộ đầy đủ: Tôi là tác giả của thư viện đó.

Làm thế nào về việc tiêm một "Trình quản lý thoát" vào Phương thức này:

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

Mã sản xuất sử dụng ExitManagerImpl và mã kiểm tra sử dụng ExitManagerMock và có thể kiểm tra xem exit () có được gọi hay không và mã thoát nào.

Bạn thực sự có thể giả định hoặc bỏ qua System.exitphương thức này, trong một bài kiểm tra JUnit.

Ví dụ: sử dụng JMockit bạn có thể viết (cũng có những cách khác):

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

EDIT: Thử nghiệm thay thế (sử dụng API JMockit mới nhất) không cho phép bất kỳ mã nào chạy sau khi gọi đến 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)");
}

Một mẹo mà chúng tôi đã sử dụng trong cơ sở mã của mình là để lệnh gọi System.exit () được gói gọn trong một hàm Runnable, phương thức được đề cập theo mặc định được sử dụng. Để kiểm tra đơn vị, chúng tôi đặt một giả lập Runnable khác nhau. Một cái gì đó như thế này:

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

... và phương pháp kiểm tra JUnit ...

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

Tạo một lớp có thể mô phỏng bao bọc System.exit ()

Tôi đồng ý với EricSchaefer . Nhưng nếu bạn sử dụng một khung mô phỏng tốt như Mockito, một lớp cụ thể đơn giản là đủ, không cần giao diện và hai triển khai.

Dừng thực thi kiểm tra trên System.exit ()

Vấn đề:

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

Một sự chế giễu Sytem.exit()sẽ không chấm dứt thực thi. Điều này là xấu nếu bạn muốn kiểm tra mà thing2không được thực thi.

Giải pháp:

Bạn nên cấu trúc lại mã này theo đề xuất của martin :

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

Và làm System.exit(status)trong chức năng gọi. Điều này buộc bạn phải có tất cả của bạn System.exit()ở một nơi trong hoặc gần main(). Điều này sạch hơn gọi System.exit()sâu bên trong logic của bạn.

Mã

Vỏ bánh:

public class SystemExit {

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

Chủ yếu:

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

Kiểm tra:

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

Tôi thích một số câu trả lời đã được đưa ra nhưng tôi muốn chứng minh một kỹ thuật khác thường hữu ích khi kiểm tra mã kế thừa. Cho mã như:

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

Bạn có thể thực hiện tái cấu trúc an toàn để tạo phương thức kết thúc lệnh gọi System.exit:

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

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

Sau đó, bạn có thể tạo giả cho bài kiểm tra của mình ghi đè thoát:

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

Đây là một kỹ thuật chung để thay thế hành vi cho các trường hợp thử nghiệm và tôi sử dụng nó mọi lúc khi tái cấu trúc mã kế thừa. Nó không thường là nơi tôi sẽ rời khỏi mọi thứ, mà là một bước trung gian để có được mã hiện có đang được thử nghiệm.

Nhìn nhanh vào api, cho thấy System.exit có thể ném một ngoại lệ đặc biệt. nếu một nhân viên an ninh cấm tắt máy vm. Có lẽ một giải pháp sẽ là cài đặt một người quản lý như vậy.

Bạn có thể sử dụng java SecurityManager để ngăn luồng hiện tại tắt máy ảo Java. Các mã sau đây nên làm những gì bạn muốn:

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

Để câu trả lời của VonC chạy trên JUnit 4, tôi đã sửa đổi mã như sau

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

Bạn có thể kiểm tra System.exit (..) bằng cách thay thế phiên bản Runtime. Ví dụ: với 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);
    }
}

Có những môi trường mà mã thoát được trả về được sử dụng bởi chương trình gọi (chẳng hạn như ERRORLEVEL trong MS Batch). Chúng tôi có các thử nghiệm xung quanh các phương thức chính thực hiện điều này trong mã của chúng tôi và cách tiếp cận của chúng tôi là sử dụng một ghi đè SecurityManager tương tự như được sử dụng trong các thử nghiệm khác ở đây.

Đêm qua tôi đã tập hợp một JAR nhỏ bằng cách sử dụng các chú thích Junit @Rule để ẩn mã trình quản lý bảo mật, cũng như thêm các kỳ vọng dựa trên mã trả về dự kiến. http://code.google.com.vn/p/junitsystemrules/

Hầu hết các giải pháp sẽ

• chấm dứt thử nghiệm (phương thức, không phải toàn bộ hoạt động) thời điểm System.exit()được gọi
• bỏ qua một cài đặt đã SecurityManager
• Đôi khi khá cụ thể cho một khung kiểm tra
• hạn chế sử dụng tối đa một lần cho mỗi trường hợp thử nghiệm

Vì vậy, hầu hết các giải pháp không phù hợp cho các tình huống:

• Việc xác minh tác dụng phụ sẽ được thực hiện sau cuộc gọi đến System.exit()
• Một người quản lý bảo mật hiện có là một phần của thử nghiệm.
• Một khung kiểm tra khác nhau được sử dụng.
• Bạn muốn có nhiều xác minh trong một trường hợp thử nghiệm. Điều này có thể không được khuyến khích, nhưng đôi khi có thể rất thuận tiện, đặc biệt là kết hợp với assertAll(), ví dụ.

Tôi không hài lòng với các hạn chế được áp đặt bởi các giải pháp hiện có trong các câu trả lời khác, và do đó tự mình nghĩ ra một cái gì đó.

Lớp sau đây cung cấp một phương thức assertExits(int expectedStatus, Executable executable)xác nhận System.exit()được gọi với một statusgiá trị được chỉ định và kiểm tra có thể tiếp tục sau nó. Nó hoạt động tương tự như JUnit 5 assertThrows. Nó cũng tôn trọng một người quản lý an ninh hiện có.

Có một vấn đề còn lại: Khi mã được kiểm tra cài đặt trình quản lý bảo mật mới thay thế hoàn toàn trình quản lý bảo mật do thử nghiệm đặt. Tất cả các SecurityManagergiải pháp dựa trên cơ sở khác mà tôi biết đều gặp phải vấn đề tương tự.

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

Bạn có thể sử dụng lớp như thế này:

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

Mã có thể dễ dàng được chuyển đến JUnit 4, TestNG hoặc bất kỳ khung nào khác, nếu cần. Yếu tố khung cụ thể duy nhất là thất bại trong bài kiểm tra. Điều này có thể dễ dàng được thay đổi thành một cái gì đó độc lập với khung (khác với Junit 4 Rule

Có chỗ để cải thiện, ví dụ, quá tải assertExits()với các thông điệp có thể tùy chỉnh.

Sử dụng Runtime.exec(String command)để bắt đầu JVM trong một quy trình riêng biệt.

Có một vấn đề nhỏ với SecurityManagergiải pháp. Một số phương pháp, chẳng hạn như JFrame.exitOnClose, cũng gọi SecurityManager.checkExit. Trong ứng dụng của tôi, tôi không muốn cuộc gọi đó thất bại, vì vậy tôi đã sử dụng

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

Gọi System.exit () là một cách thực hành tồi, trừ khi nó được thực hiện bên trong main (). Các phương thức này sẽ đưa ra một ngoại lệ, cuối cùng, được bắt bởi main () của bạn, người sau đó gọi System.exit với mã thích hợp.