Re: Unit test candidates

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.

-J.

-- 
Jesse Glick <mailto:[email protected]> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>