Testing main method by junit

We Are Going To Discuss About Testing main method by junit . So lets Start this Java Article.

Testing main method by junit

  1. Testing main method by junit

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

  2. Testing main method by junit

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

Solution 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.

Original Author G_H Of This Content

Solution 2

IMO the best way to test the main method is by having the main method do absolutely nothing but set up the world and kick it off. This way one simple integration test gives the answer “has the world been set up”.

Then all the other questions become much easier to answer.

The main method calls different methods for different console inputs and it calls different function for different arguments.

It should not, it should call someService.somemethod(args). This service gets tested like any other.

So i want to test this main method with Junit by mimicking these inputs from a file. how can i do it?

Either some form of fakes injected in or the use of the TemporaryFolder JUnit rule.

Original Author Michael Lloyd Lee mlk Of This Content

Solution 3

You can call main method from junit test like this:

YourClass.main(new String[] {"arg1", "arg2", "arg3"});

But since main method is void and does not return anything, you should test object that changed after main invocation;

Here is Link How do I test a method that doesn’t return anything?

Original Author Davit Mumladze Of This Content

Conclusion

So This is all About This Tutorial. Hope This Tutorial Helped You. Thank You.

Also Read,

Siddharth

I am an Information Technology Engineer. I have Completed my MCA And I have 4 Year Plus Experience, I am a web developer with knowledge of multiple back-end platforms Like PHP, Node.js, Python and frontend JavaScript frameworks Like Angular, React, and Vue.

Leave a Comment