At the start of this conversation I offered the following example of using
a mock application context:
GeoServerResourceLoader resourceLoader = new
GeoServerResourceLoader(baseDirectory);
ApplicationContext context =
createNiceMock(ApplicationContext.class);
expect(context.getBean("resourceLoader")).andReturn( resourceLoader
);
expect(context.getBeanNamesForType(GeoServerResourceLoader.class)).andReturn(new
String[]{"resourceLoader"}).anyTimes();
expect(context.getBeanNamesForType((Class)anyObject())).andReturn(new
String[]{}).anyTimes();
replay(context);
The only part that is hard to understand is the anyObject --> new String[]
entry, basically saying "no" to any unknown singleton lookups.
If you can name a good place to put this boiler plate code I am fine with
that.
Jody Garnett
On Wed, Apr 23, 2014 at 6:51 AM, Justin Deoliveira <
[email protected]> wrote:
>
>
>
> On Tue, Apr 22, 2014 at 2:22 PM, Jody Garnett <[email protected]>wrote:
>
>> Thanks for the background Kevin, wish I had put this one off (or at least
>> not tied it to the work I am doing). Note this approach is not specific to
>> accessing GeoServerResourceLoader as we have several singletons.
>>
>> I will move the static init methods to a separate testing
>> GeoServerExtensionsSupport class so we have a way to accomplish what you
>> would like - that does not add to the public API.
>>
>
> Well if it's easier to throw them on GeoServerExtensions i am ok with
> that... but cleaner imo would be a helper that makes it easy to mock up or
> hack the application context directly and then just set that on
> GeoServerExtensions. You're call.
>
>>
>> Jody Garnett
>>
>>
>> On Wed, Apr 23, 2014 at 5:03 AM, Kevin Smith <[email protected]>wrote:
>>
>>> My suggestion on the pull request was just that the static calls to the
>>> GeoServerExtensions singleton might be a problem developing more unitary
>>> unit tests (I'd run into the same issue the day before) and it might be
>>> worth handling it in a way that made it easier to mock while we were
>>> changing things as long as it didn't add to much work. I was thinking
>>> along the lines of just giving the classes protected/package
>>> getResourceLoader methods that could be overridden for the objects to be
>>> tested. A better way of doing this, or if there already is a way that
>>> hidden somewhere would be nice, but it's not worth holding up the pull
>>> request for and I've no problem accepting it with the static calls in place.
>>>
>>>
>>> On 22 April 2014 07:17, Jody Garnett <[email protected]> wrote:
>>>
>>>>
>>>>>> You're not being clear about the motivation here, or at least i can't
>>>>> infer it from this conversation. Can you just point me at a specific test
>>>>> case that Kevin has written.
>>>>>
>>>>
>>>> In the current codebase look for any/all examples of
>>>> GeoserverDataDirectory.setResourceLoader.
>>>>
>>>> * MockCreator.createCatalog - this is the key gotcha that effects many
>>>> test cases
>>>> * DefaultGeoServerLoaderTest
>>>> * FileExistsValidatorTest
>>>> * PyCatalogModTest
>>>>
>>>> Here is an example use from PyCatalogModTest.java:
>>>>
>>>> Previously:
>>>>
>>>>
>>>> *GeoserverDataDirectory.setResourceLoader(scriptMgr.getDataDirectory().getResourceLoader());*
>>>>
>>>> The replacement would be:
>>>>
>>>> *GeoServerExtensions.init("resourceLoader",
>>>> scriptMgr.getDataDirectory().getResourceLoader() );*
>>>>
>>>> This is due to code now using GeoServerExtensions (rather than
>>>> GeoserverDataDirectory) to look things up.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Start Your Social Network Today - Download eXo Platform
>>>> Build your Enterprise Intranet with eXo Platform Software
>>>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>>>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>>>> http://p.sf.net/sfu/ExoPlatform
>>>> _______________________________________________
>>>> Geoserver-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Kevin Smith
>>>
>>> Junior Software Engineer | Boundless
>>>
>>> [email protected]
>>>
>>> +1-778-785-7459
>>>
>>> @boundlessgeo <https://twitter.com/boundlessgeo>
>>>
>>
>>
>
>
> --
> *Justin Deoliveira*
> Vice President, Engineering | Boundless
> [email protected]
> @j_deolive <https://twitter.com/j_deolive>
>
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
