Question

I’ve got a few methods that should call System.exit() on certain inputs. Unfortunately, testing these cases causes JUnit to terminate! Putting the method calls in a new Thread doesn’t seem to help, since System.exit() terminates the JVM, not just the current thread. Are there any common patterns for dealing with this? For example, can I substitute a stub for System.exit()?

The class in question is actually a command-line tool which I’m attempting to test inside JUnit. Maybe JUnit is simply not the right tool for the job? Suggestions for complementary regression testing tools are welcome (preferably something that integrates well with JUnit and EclEmma).

Answer 1

Indeed, Derkeiler.com suggests:

• Why 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.

• Prevent System.exit() to actually exit the 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);         }     } } 

---

Update December 2012:

Will proposes in the comments using System Rules, a collection of JUnit(4.9+) rules for testing code which uses java.lang.System.
This was initially mentioned by Stefan Birkner in his answer in December 2011.

System.exit(…) 

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

For instance:

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

---

2023: Emmanuel Bourg reports in the comments:

For this to work with Java 21 this system property must be set -Djava.security.manager=allow