I believe the surefire tests are executed in the
verify phase of the default lifecycle. Please, check http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html to make sure you're not making a mistake by using mvn install in this context.
Also, I don't see any problem if an Eclipse plug-in depends on Eclipse Platform, but I may miss something. Anyway, getResourceAsStream() sounds like a good alternative to me. Why did you have to use manual file-copying instead of it?
/Mikhail
Från: "Dirk Fauth" <dirk.fauth@xxxxxxxxx>
Till: "Tycho user list" <tycho-user@xxxxxxxxxxx>
Skickat: fredag, 6 sep 2013 13:10:40
Ämne: Re: [tycho-user] getResource() in test cases
Hi,
thanks for the replies. I was digging into this a bit deeper regarding your answers and found out several facts. So to help others who face the same issues, here are my results:
1. The surefire tests are only executed in the install phase. Personally this is confusing, as I tried to build my shortened examples using "mvn test" and "mvn package" as I didn't wanted to install it. And no tests where executed. They are only executed when executing "mvn install". Maybe not a big deal and necessary to ensure correct test execution, but IMHO confusing. So you need to be aware of that when using Tycho.
2. With the answers of Mickael Istria and Mikhail Karkov I was able to find out what's going on. It is very important to know that the tests are executed against the packaged plugin jar. Because of this, the URL changes in test execution. While executing the test in the IDE the URL is a "file:/" URL, executing the test with Tycho it will be a "bundleclass:/" URL. Using Java File or NIO API, the file can not be loaded with conventional methods if the URL starts with "bundleclass".
So how to solve this?
The solution mentioned by Mikhail Karkov is a possible workaround, but IMHO it is not a very elegant one. Because in that case I am forced to implement my test cases with a quite hard dependency to the environment. If I simply want to test some file util classes, I don't want to deal with that.
I tested and verified two possible workarounds that look a bit more environment independent.
1. Use getResourceAsStream() instead of getResource()
If you only need to read from the file, you don't need the File reference. The returning InputStream can be used to read from the file perfectly. There is no need to deal with the environment in that case.
2. Copy the resources out of the jar into a file system location and operate on that resource instead of a plugin resource
This is the only solution I've found so far to make file operation tests work. So the process for testing need to be:
- copy the necessary resources to the file system
- operate on those resources instead of the ones in the plugin jar
- after execution cleanup the created resources
Possibly in this case a TestSuite wrapper can be used to ensure the copy and cleanup code in @BeforeClass and @AfterClass as explained here:
http://stackoverflow.com/questions/6580670/testsuite-setup-in-junit-4
But I haven't tested that yet and will modify my test cases now to see if that works too.
Hopefully my investigation helps others with the same issues. If my results are wrong, please let me know!
Greez,
Dirk
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user