Skip to main content

[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

Back to the top