[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] converting dsf-gdb test plug-in into a fragment
|
Sure. Say the production plugin has a class
com.acme.editor.handlers.MyHandler
and that it has a default (package) static method
foo. In
the test plugin com.acme.test, I create the class
com.acme.editor.handlers.MyHandlerTest
and in one of its test methods I call
MyHandler.foo(). That
builds fine because the production class and the test class are in the
same package. But when the test runs as a PDE Junit test[1], you get a
runtime exception. If the test class is in a fragment, no
problem.
Check out:
http://rcpquickstart.wordpress.com/2007/06/20/unit-testing-plug-ins-with-fragments/
John
[1] If you run the test with a regular JUnit launch configuration, there
are no runtime problems. Of course, a lot of what we test requires a PDE
JUnit launch configuration.
At 03:25 PM 1/20/2011, Marc Khouzam wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_F7CE05678329534C957159168FA70DEC5730F79E8EEUSAACMS0703e_"
I see.
Do you have an example of something you are trying to access that you
cannot, at runtime?
Thanks
- From: cdt-dev-bounces@xxxxxxxxxxx
[
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John
Cortell
- Sent: Thursday, January 20, 2011 3:56 PM
- To: CDT General developers list.; 'CDT General developers
list.'
- Subject: Re: [cdt-dev] converting dsf-gdb test plug-in into a
fragment
- Actually, that technique you used is needed whether or not the test
plugin is a fragment. What you're doing there is getting around
compile-time visibility barriers. Making the test project a fragment
gets around runtime access barriers resulting from the fact that each
plugin has its own classloader.
- Another way to say that is: without your accessor class, you wouldn't
have been able to code the the tests; the compiler would have blocked
you. However, even with your solution, you could have run into
IllegaAccessError exceptions at runtime. That's what's prevented by
turning the project into a fragment.
- John
- At 02:30 PM 1/20/2011, Marc Khouzam wrote:
- BTW, I got around this limitation up to now by using an
- accessor class that I put in the test plugin but using
- the same package name as the class I want to access.
- Look at the class ClassAccessor
- Marc
- > -----Original Message-----
- > From: cdt-dev-bounces@xxxxxxxxxxx
- > [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
- > Sent: Thursday, January 20, 2011 2:21 PM
- > To: CDT General developers list.
- > Subject: [cdt-dev] converting dsf-gdb test plug-in into a
fragment
- >
- > I'd like to change
- >
- > org.eclipse.cdt.tests.dsf.gdb
- >
- > to be a fragment, so that the tests can access non-public fields
and
- > methods. It's common practice for tests to be housed in
fragments, to
- > avoid the OSGi-imposed runtime barrier between plug-ins (every
- > plug-in gets its own classloader).
- >
- > I have the changes on my machine and it all seems to be working
well.
- > Any objections?
- >
- > John
- >
- >
- >
- > _______________________________________________
- > cdt-dev mailing list
- > cdt-dev@xxxxxxxxxxx
- >
https://dev.eclipse.org/mailman/listinfo/cdt-dev
- >
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@xxxxxxxxxxx
-
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev