Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Maven run of the test cases produces 15 failures in Windows. #1

Open
FishOfPrey opened this issue Sep 29, 2014 · 16 comments
Open

Maven run of the test cases produces 15 failures in Windows. #1

FishOfPrey opened this issue Sep 29, 2014 · 16 comments

Comments

@FishOfPrey
Copy link
Contributor

Calls to FileString.getStringFromFile(String Path) are returning strings that have both LF and CRLF as the delimiter in a Windows environment.

This results in 15 test failures when comparing the WSDL2Apex output with the expected output files.


Test set: com.salesforce.ide.wsdl2apex.core.WSDL2ApexTest

Tests run: 47, Failures: 15, Errors: 0, Skipped: 0, Time elapsed: 0.686 sec <<< FAILURE!
testAsyncFalse(com.salesforce.ide.wsdl2apex.core.WSDL2ApexTest) Time elapsed: 0.032 sec <<< FAILURE!
org.junit.ComparisonFailure: Test 8 doesn't match expected:<> but was:<...nerated by wsdl2apex[

]
}> but was:<...nerated by wsdl2apex[
}]
}>
at org.junit.Assert.assertEquals(Assert.java:115)

testNewClassNames(com.salesforce.ide.wsdl2apex.core.WSDL2ApexTest) Time elapsed: 0.038 sec <<< FAILURE!

The result1 output of parseAndGenerate(args) has the extra CR.

My quick hack solution is to modify the return statement of FileString.getStringFromFile() by appending .replaceAll("\r\n", "\n").

Also, are the last two arguments to assertEquals around the correct way? Should the expected value go first and then the actual value?

I might be off the mark of both these points as I don't usually work with Java.

@vazexqi
Copy link
Contributor

vazexqi commented Sep 29, 2014

@FishOfPrey : Thanks for reporting this. I'll take a look. I don't have quick access to a Windows machine so this might take some time.

As for the assertEquals, yes, the order of the arguments is expected first and then actual after that. Thanks for spotting that. Would you be able to make this change?

@FishOfPrey
Copy link
Contributor Author

@vazexqi Yes, I'll look at verifying the order of the assertEquals arguments. It will be a good first pull request as I get my dev environment setup with Maven etc... Thanks.

@vazexqi
Copy link
Contributor

vazexqi commented Sep 29, 2014

@kren708: Feel free to chime in as well since you've worked more with the code.

FishOfPrey added a commit to FishOfPrey/WSDL2Apex that referenced this issue Sep 29, 2014
Changed the argument order for assertEquals so that the expected answer is before the actual result. As per Issue forcedotcom#1 and http://junit.sourceforge.net/javadoc/org/junit/Assert.html
@sunderkonda
Copy link

Same here, I was able to clone the repo but when i try to build it using "mvn install package" I also got 15 failures. I'm stuck there and spent lot of time reinstalling and everything and also in a different machine but the same issue again. I'm using windows 7.

@dancinllama
Copy link

I get 12 errors on Mac OS X (Yosemite), running from a 1.8 jdk, I can send the log from mvn install package if needed.

@vazexqi
Copy link
Contributor

vazexqi commented Oct 20, 2014

@dancinllama: What are the errors that you are getting? I just tried on Mountain Lion and Maverick and both ran all 47 tests.

@dancinllama
Copy link

Sent the test results to your email address, vazexqi.

@vazexqi
Copy link
Contributor

vazexqi commented Oct 20, 2014

@dancinllama: What version of Java and maven are you running? I'm not sure if it is a configuration issue but it might help narrow it down. For reference, I'm on Java 1.7 and Maven 3.0.5.

@dancinllama
Copy link

Jdk 1.8.0_25 and Apache Maven 3.2.3 (Installed via homebrew)

@clabrosse
Copy link

There was a jdk update in the Yosemite update, it bit me on my home
computer too, things stopped working. You can go get the older version and
things will likely work as they did before

Sent from my iPhone

On Oct 20, 2014, at 9:02 AM, Nicholas Chen [email protected] wrote:

@dancinllama https://github.com/dancinllama: What version of Java and
maven are you running? I'm not sure if it is a configuration issue but it
might help narrow it down. For reference, I'm on Java 1.7 and Maven 3.0.5.


Reply to this email directly or view it on GitHub
#1 (comment).

@vazexqi
Copy link
Contributor

vazexqi commented Oct 21, 2014

@dancinllama: It's because of Java 8. I installed it on my laptop with Mountain Lion and it gave me the same failures as what you sent me. Could you fall back to Java 7?

@jkraybill
Copy link

I've received 15 errors both under JDK 7 and 8 under Windows 8. Attached is my verbose error log.

output2.txt

@conrjac
Copy link

conrjac commented Jan 14, 2016

I am getting the same issues on Windows 10 - has anyone got a work around? I am happy to help work on a resolution on this issue if anyone has some suggestions.

@kren708
Copy link

kren708 commented Jan 15, 2016

Looking at the output, it seems that the difference just seems to be the
whitespace at the end of the files. Perhaps, you can try trimming both the
original and the generated outputs.

On Thu, Jan 14, 2016 at 10:02 AM, Connor Jackson [email protected]
wrote:

I am getting the same issues on Windows 10 - has anyone got a work around?
I am happy to help work on a resolution on this issue if anyone has some
suggestions.


Reply to this email directly or view it on GitHub
#1 (comment)
.

@vazexqi
Copy link
Contributor

vazexqi commented Apr 19, 2016

@kren708 - Could you take a look at these Java 8 failures? We have updated to Java 8 for the Force.com IDE and it's time to do the same for Apex2WSDL.

@jkraybill
Copy link

A workaround to simply skip the maven test step is to add "-DskipTests=true" to your call to mvn, e.g. "mvn install package -DskipTests=true"

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants