Alessandro Argentieri
Alessandro Argentieri

Reputation: 3215

Unit tests using InputStream pass in IntelliJ but fail in Maven

I'm testing a class which validates the XML content of an InputStream. So I'm passing various XML Strings according to the assertion I want to get.

The weird thing is that when I run the tests from my Test Class they all pass. When I run the tests through Maven (install or test command is the same), then the assertions are wrong because they return always an empty String (I want to get the Error String: empty if the XML is well formed, with the description of the errors if the XML in input is not well formed according to the criteria of my specific project).

Here I attach a test example which passes if run from the test class command, and fails when it is executed with maven test command:

@Test
public void NumeroTagDifformeListaProcessi() throws IOException {
    InputStream inputStream = IOUtils.toInputStream("<?xml version='1.0' encoding='UTF-8'?><RequestModel><codiceProdotto>GFDT4536</codiceProdotto><numeroPolizza>12345</numeroPolizza><numeroPropComp>5463</numeroPropComp></RequestModel>", "UTF-8");
    assertEquals("Il numero dei tag non corrisponde al modello. Il tag banca e' mancante nella richiesta. ", RequestValidator.validate(inputStream, RequestModel.class, "requestmodel"));
}

Here it's the error returned by Maven:

Failed tests: 
RequestValidatorTest.NumeroTagDifformeListaProcessi:42 expected:<[Il numero dei tag non corrisponde al modello. Il tag banca e' mancante nella richiesta. ]> but was:<[]>

Upvotes: 0

Views: 282

Answers (1)

Ferrybig
Ferrybig

Reputation: 18834

Your problem is caused by conflicting unit tests.

There are multiple causes for this:

  • Inappropriate use of a global application cache

    Sometimes, multiple unit tests may access the same cache, if this class isn't written with correct thread-safety in mind, this will cause conflicts

  • Inappropriate use of static variables

    If a method under test uses static variables, but never resets them inside the method itself (as opposed to resetting (initializing) them when the class is constructed), this will cause problems.

  • File/class/method ordering

    Different test runners may execute the tests in different order, even on the same platform, most tools on Windows execute tests in alphabetic order, but some do it in order of aAb.YzZ, and others in abc...XYZ, this may even extend to the actual methods of a class file (java file method order, class file method order, or even alphabetic order)

  • Race conditions exposed by garbage collection

    Some code can be vulnerable for race conditions, if the garbage collection kicks in during the unit test it may push it far enough to cause bugs (or hide the bugs)

Upvotes: 1

Related Questions