Re: Unit test candidates

Jesse Glick wrote:

> Petr Kuzel wrote:
>> To test these in unit like manner a lot of mock objects must be
>> created: WindowManager, TopComponent.Registry, DataObject.Registry,
>> etc. Therefore my second question is: What is better practice:
>> 
>> - introduce simpler interfaces with lookup mechanism, their
>> implementations (delegating to original objects) and for unit testing
>> their mockups
>> 
>> - write mockups for exiting objects and prepend them to unit test
>> classpath (simplification there exists one class in openide called
>> ActionsInfraHid.UsefulThings that mocks TopComponent.Registry)?
>> 
>> Any suggestions and experiences?
> 
> In my experience, the second style can work fine. (And if your code is
> nicely designed, most of it won't need many of these services anyway;
> only a thin GUI layer will need to use them heavily.)
> 
> You don't need to *prepend* mockups impls to unit test classpath, so
> long as the standard core impls are *not* in the classpath. Also
> remember you can configure default lookup to be whatever you want it to
> be, in a normal forked unit test; I like to set it to a proxy of
> Lookups.metaInfServicesLookup(TheUnitTest.class.getClassLoader()) plus a
> Lookups.fixed of whatever is needed for that particular test.

I took the first one and it works too :-). Code being tested depends on
SFS and Lookup registrations provided by modules. Recently I got hint that I
can use Lookup.getDefault().lookup(ModuleInfo.class) to kick up
module system then being able to locate these registrations.

  Cc.

-- 
<address>
<a href="mailto:[email protected]">Petr Kuzel</a> at Sun Microsystems :
<a href="http://www.netbeans.org/">NetBeans Java IDE</a></address>