Instead of the suggestions above (edit: I noticed that Bart left this idea in a comment as well), I would suggest making your class more unit testable by making the class accept the input source as a constructor parameter or similar (inject the dependency). A class shouldn't be so coupled to System.in anyway.
If your class is constructed from a Reader, you can just do this:
class SomeUnit {
private final BufferedReader br;
public SomeUnit(Reader r) {
br = new BufferedReader(r);
}
//...
}
//in your real code:
SomeUnit unit = new SomeUnit(new InputStreamReader(System.in));
//in your JUnit test (e.g.):
SomeUnit unit = new SomeUnit(new StringReader("here's the input\nline 2"));
System.in
, eventually you will want to test the module that takes the data fromSystem.in
. – RubberneckSystem.in
are not really doing a complete job of that though, since System.in no longer reads from standard in which is what the application will be using. You're really not testing anything except for maybe whether the System class functions properly, which I assure you has been tested by Sun. – BrowbeatSystem.in
. You can automate the tests instead of having users enter in test data through a console. – RubberneckSystem.in provides
. The application shouldn't care where that data is coming from. When run in a production setting, it will be coming from a keyboard, but in the test, it will be coming from a text file, or some hard coded strings. You are testing the ability of your application to handle different types of inputs. – Rubberneck