2

Here is the code for a simple test case I am doing right now : 

private static final ByteArrayOutputStream OUTCONTENT = new ByteArrayOutputStream();
private static final PrintStream OLD_STD_OUT = System.out;

@Before
public  void setUp() {       
    System.setOut(new PrintStream(OUTCONTENT));
}

@After
public  void tearDown(){
     System.setOut(OLD_STD_OUT);
}

@Test
 public void consolePrintResetTest(){
     consolePrintReset();
     assertEquals("Les statistiques ont été réinitialisées avec succès! \n", OUTCONTENT.toString());
}

and the method I am testing: 

 public static void consolePrintReset(){
       System.out.println("Les statistiques ont été réinitialisées avec succès!");
 }

And here a screenshot of what happens: http://puu.sh/vpY3b/9a398d0b41.png

I'm pretty sure it's something really dumb i'm passing over, but I don't find what obvious thing i'm missing to make this test case work. Any help would be greatly appreciated.

Thank you for taking the time to read my question!

GhostCat
  • 137,827
  • 25
  • 176
  • 248
Alexandre Fernandes Bartolomeu
  • 2,936
  • 2
  • 12
  • 18

2 Answers2

2

The point is that your assert expects " \n" at the end of the line. But the line break does depend on your operating system.

Thus: simply call trim() on the captured output string and remove that line break from your expected result.

Edit on the comments by OP:

  • In a real world application, one does normally not write to System.out; if at all, you are using some logging framework.
  • There is also not much point in checking that an output looks exactly as you expect it. That means each time you change a message, the test will break. Not helpful.
  • If at all, one would rather make sure that some logger object for example saw a specific log call, "containing" some important keyword or so.
  • In your case, it is not clear, what you intend to achieve! You see, when you invoke some "method under test"; the code in there gets executed; and when there is a System.out.println() call; that call gets counted for your coverage when it happens. Adding a testcase that checks the writing took really place doesn't help with your coverage at all. Keep in mind: you measure the coverage of your production code. Testing if System.out.print works (it usually does ;-) doesn't help the coverage within your production code.
GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Thank you, that was the problem! – Alexandre Fernandes Bartolomeu Apr 20 '17 at 02:55
  • I do am curious. I understand why it doesn't provide much value, but if you have more information about it i'm always happy to learn some new things. As to why I am testing this is for an assignement. I need to do 80% test coverage and that represents over 300 tests according to the code coverage report. So if I can do some fast ones I'm happy about it, no matter how useful they are (since that is not graded for this assignement). – Alexandre Fernandes Bartolomeu Apr 20 '17 at 03:10
  • @AlexandreFernandesBartolomeu The updates are there ;-) – GhostCat Apr 20 '17 at 06:14
  • Thank you for for the added informations! That makes perfect sense. That part about checking for certain keywords is actually a great idea. You are right lol that i'm basically just testing if System.out works. – Alexandre Fernandes Bartolomeu Apr 20 '17 at 14:50
2

Apparently, the spurious space in your unit test is your attempt to fix the problem, and problem is still there without it. (See comments on Question.)

In that case, the problem is most likely that your system's line separator is not a simple newline character. Here's how to write the test to be test platform independent; i.e. to work on Windows, Linux and MacOSX ...

 public void consolePrintResetTest(){
     consolePrintReset();
     assertEquals("Les statistiques ont été réinitialisées avec succès!" 
                  + System.lineSeparator(), OUTCONTENT.toString());
 }

Alternatively, you could strip off the line terminator (and any other leading / trailing whitespace) using trim().

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216