Testing main method by junit [duplicate]

Question

I wrote a class which takes input from console and arguments in main method. The main method calls different methods for different console inputs and it calls different function for different arguments. So i want to test this main method with Junit by mimicking these inputs from a file. how can i do it? Is there any special provision in junit to test the main method of the class?

Answer 1

To provide the input from a file, make a FileInputStream and set that as the System.in stream. You'll probably want to set the original back after the main method has finished to make sure anything using it later still works (other tests, JUnit itself...)

Here's an example:

@Test public void testMain() throws IOException {     System.out.println("main");     String[] args = null;     final InputStream original = System.in;     final FileInputStream fips = new FileInputStream(new File("[path_to_file]"));     System.setIn(fips);     Main.main(args);     System.setIn(original); } 

In your actual code you'll want to handle any IOExceptions and use something better than a full path to the file (get it via the classloader), but this gives you the general idea.

---

EDIT:

A couple years and some more wisdom later, I'd have to agree with Michael Lloyd Lee mlk's answer as the better approach and what should be preferred if possible. In the class containing your main method (or even a separate class) there ought to be a method that accepts an arbitrary InputStream and the arguments array. It could be a static method. The main method then simply calls it with the System.in stream as argument.

public class Main {     public static void main(String[] args) {         start(System.in, args);     }     public static void start(InputStream input, String[] args) {         // use input and args     } } 

Or alternatively you could have a class with a constructor accepting the arguments array to create a properly configured instance and then call an instance method on it that accepts an InputStream, like so:

public class Main {     public static void main(String[] args) {         Bootstrapper bootstrapper = new Bootstrapper(args);         bootstrapper.start(System.in);     } }  public class Bootstrapper { // just some name, could be anything else      // could have some instance fields here...          public Bootstrapper(String[] args) {         // use the args to configure this instance, set fields, get resources...     }          public void start(InputStream input) {         // use input     } } 

Whatever fits the requirements and program design best. In both cases you end up with something that can be unit-tested with an InputStream obtained from a file. A test doing a simple static method call to Main.start, or a test creating a Bootstrapper instance and then calling its start method. Now your testing is no longer dependent on the System.in stream. The main method does minimal work and is simple enough for you to just trust its correctness without a separate test. At some point a piece of code becomes so trivial that testing it is equivalent to distrusting the compiler. And an issue in these main methods would become apparent very soon as it's the one method you know will always be called. A main method that does too much or is complex usually points to a lack of modularization in the code.

I leave the original answer in because it does offer a solution in case you really can't get past the use of System.in and testing the main method. That's why I wrote it in the first place, because I couldn't be certain about the asker's constraints. Sometimes someone just wants a straight answer to their exact question because the better approach is not available; you're not allowed to change the code, or refactoring it is too much effort and there's no budget, or some library is used that is hardcoded to use the system streams etc. Note that the original answer is less robust anyway. If the tests are run in parallel instead of sequentially, swapping out a system stream could cause unexpected and inconsistent failures.