|
|
| Re: -> IllegalAccessError using JUnit PDE Test [message #92122 is a reply to message #91778] |
Thu, 04 September 2003 08:51   |
 Eric Estievenart
Messages: 64
Registered: July 2009 |
Member |
|
|
Yes I had seen this trick, but it does not suit me perfectly,
for the following reasons:
- First having test & prod code in the same project may be dangerous
if the test code goes into production (!)
- Then the test code depends on specific support classes, which are shared
between various testing projects, and the prod code has not to depend
on them, so the dependencies would be different whether we
are compiling for prod or development...
- And now the test project is a real plugin, which allows to perform
specific testing actions, and its actions are not to be in the production
plugin.xml
I'll do with ugly public methods for now, but it would be ok
if there was some kind of "friend plugins" declaration possibility
in the plugin.xml. Even if this is a real security issue, but for me
it is the only real clean way. (And security could anyway be enforced
through signatures or something like that)
--Steve
On Wed, 3 Sep 2003 15:32:58 +0200, Martin Kersten
> Since it was me who started the topic here is what works great:
> Just add a second source folder called src-test and place your tests
> in there. Your test code is now running within the same plugin as
> your normal one. (Use the same bin directory for both). Now you
> have access to everything. To get the product simply remove all
> unnecessary classes using tools or just remove the src-test folder
> (use a second workbench on that).
>
> Hope that helps ;)
>
>
> Martin (Kersten)
>
>
>
|
|
|
| Re: -> IllegalAccessError using JUnit PDE Test [message #92654 is a reply to message #92122] |
Fri, 05 September 2003 06:10 |
Martin Kersten
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
One think that works also is to subclass the class on which you want to
have protected access level. And you can also use the none-pde test
to test models and stuff. You know using the none-pde test suite
gives you the protected level as well ;) Thats what I ve done before
merging both.
Martin (Kersten)
"Eric Estievenart" <eric.estievenart@peregrine.com> schrieb im Newsbeitrag
news:opruyv8sii9ck0a6@localhost...
>
> Yes I had seen this trick, but it does not suit me perfectly,
> for the following reasons:
>
> - First having test & prod code in the same project may be dangerous
> if the test code goes into production (!)
>
> - Then the test code depends on specific support classes, which are shared
> between various testing projects, and the prod code has not to depend
> on them, so the dependencies would be different whether we
> are compiling for prod or development...
>
> - And now the test project is a real plugin, which allows to perform
> specific testing actions, and its actions are not to be in the
production
> plugin.xml
>
> I'll do with ugly public methods for now, but it would be ok
> if there was some kind of "friend plugins" declaration possibility
> in the plugin.xml. Even if this is a real security issue, but for me
> it is the only real clean way. (And security could anyway be enforced
> through signatures or something like that)
>
>
> --Steve
>
>
> On Wed, 3 Sep 2003 15:32:58 +0200, Martin Kersten
>
> > Since it was me who started the topic here is what works great:
> > Just add a second source folder called src-test and place your tests
> > in there. Your test code is now running within the same plugin as
> > your normal one. (Use the same bin directory for both). Now you
> > have access to everything. To get the product simply remove all
> > unnecessary classes using tools or just remove the src-test folder
> > (use a second workbench on that).
> >
> > Hope that helps ;)
> >
> >
> > Martin (Kersten)
> >
> >
> >
>
>
|
|
|
|
| Re: -> IllegalAccessError using JUnit PDE Test [message #94156 is a reply to message #92669] |
Wed, 10 September 2003 18:06 |
Eric Estievenart
Messages: 64
Registered: July 2009 |
Member |
|
|
On Fri, 5 Sep 2003 11:58:30 +0200, Martin Kersten
<Martin.Kersten@student.uni-magdeburg.de> wrote:
>> One think that works also is to subclass the class on which you want to
>> have protected access level. And you can also use the none-pde test
>> to test models and stuff. You know using the none-pde test suite
>> gives you the protected level as well ;) Thats what I ve done before
>> merging both.
Well, it is a bit painful, and even more when you don't control
the class allocation, because for example you are testing a class
instance which has been allocated by another, generally indirectly.
What I want is really to access default members, which were generally
private and promoted to 'default' for this purpose (not that I am
paranoid ;-)
This also must be simple and straightforward, because people already
tend not to make tests at all (sic).
> I think this wouldn't be such a big problem. The
> problems start when to test indirect. Like
> toTest.getPart().packageMethod();
>
> This is untestable. But I guess it is not that much of use
> to test packageMethods at this level.
I let you imagine that my test is like :
. connect to a database
. execute many commands to display forms
. lookup at the forms internals
. ...
so as you say, it is not testable using what you preconize ;-)
There is also another way, which is to make all members of the tested
classes accessible through reflection in the test
project. It does not impact the production code, and does not
clutter the production classes with widely accessible test methods.
> Did you tested this behaviour using the current Eclipse 3.0
> milestone release? If it isn't providing that level of access or
> any method to gain it, I would like to file in a bug report.
I did not test it against 3.0, maybe I'll try next week.
For me there are 2 bugs :
- The IllegalAccessError
- The fact that eclipse let the test project compile.
--Steve
|
|
|
| Re: -> IllegalAccessError using JUnit PDE Test [message #95822 is a reply to message #94156] |
Mon, 15 September 2003 16:38 |
Martin Kersten
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi Eric,
> This also must be simple and straightforward, because people already
> tend not to make tests at all (sic).
Thats why I use test first. First write the test then the implementation ;)
Its more fun, its more secure and nearly 100% test covered
(beside some execution paths ;)
> > This is untestable. But I guess it is not that much of use
> > to test packageMethods at this level.
>
> I let you imagine that my test is like :
> . connect to a database
> . execute many commands to display forms
> . lookup at the forms internals
> . ...
>
> so as you say, it is not testable using what you preconize ;-)
Thats a 100% mock situation ;) Think about extending the forms
and check every single step that is done on them. You know something
like if an label is added, check the label and verfiy it. Was it expected
there? etc.
Or think about a logger or compare a precalculated and manually
checked result against the result of your test.
> There is also another way, which is to make all members of the tested
> classes accessible through reflection in the test
> project. It does not impact the production code, and does not
> clutter the production classes with widely accessible test methods.
Reflection didn't worked for me here. Throws also IllegalAccessException
here (checked it ;).
> > Did you tested this behaviour using the current Eclipse 3.0
> > milestone release? If it isn't providing that level of access or
> > any method to gain it, I would like to file in a bug report.
>
> I did not test it against 3.0, maybe I'll try next week.
> For me there are 2 bugs :
> - The IllegalAccessError
> - The fact that eclipse let the test project compile.
Well the illegal access exception /error is a runtime behaviour
special to the way plugins are loaded and classes are shared.
The compile without error isn't a bug. There are implementations
possible which run your code well. So the compiler is right to
declare it as '100% correct' java code ;)
Martin (Kersten)
|
|
|
Powered by
FUDForum. Page generated in 0.04078 seconds
] 
Search
Help
Register
Login
Home
