the mocks implement only a certain level of functionality, and not all features of the relevant interfaces. some methods just throw "unsupportedoperation" exception.
they are currently focused on features that "normal" application and component logic for sling apps require. the intro pages of the documentations listed below have some bullets about whats supported and what not. advanced features like JCR search, transactions, versioning, observation are currently not supported, although for some of them it would be possible to add them later as required. we're using these mocks already for several complex projects and features e.g. for http://wcm.io, and you can get really far with what's supported currently, although in some cases you have to know how the mocking is working to correctly setup you unit test. this will be covered in the documentation. stefan >-----Original Message----- >From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian >Boston >Sent: Friday, October 10, 2014 12:52 PM >To: dev@sling.apache.org >Subject: Re: [PROPOSAL] donate sling-mock, jcr-mock, osgi-mock to Apache >Sling > >Hi, >This would be a great addition. I frequently spend hours building >mockito based mocks to do the same and although the first time it was >fun, it gets a real pain the n'th time. Although you can do the same >with a real OSGi Unit test and an in memory version of Jackrabbit, the >runtime of each unit test often adds to much to the overall build >time. > >I am +1 on this if it came to a vote. > >Are there any areas where these Mocks wont work ? >Multiple threads, observation, locks, versioning ? > > >Best Regards >Ian > > >On 10 October 2014 09:10, Stefan Seifert <sseif...@pro-vision.de> wrote: >> in the last week i've developed at suite of mocking libraries to run >OSGi/SCR, JCR and esp. Sling in a simulated "in-memory" environment for unit >tests, ensuring minimal setup time. it uses either a mocked in-memory JCR, or >the resourceresolver-mock [1] implementation that is already part of the >sling project. additional convenience features like bulk-loading JSON content >and binaries into the simulated resource tree via a content loader makes it >easy setting up complex text fixtures for your unit tests. >> >> the mocking libraries are currently documented at: >> - http://wcm.io/testing/osgi-mock/ >> - http://wcm.io/testing/jcr-mock/ >> - http://wcm.io/testing/sling-mock/ >> >> some documentation examples to see how it works: [2], [3], [4] >> types of resource resolver implementations supported: [5] >> a short introduction from adaptTo: [6] >> >> i would donate this with full unit test coverage and documentation to >apache sling and can maintain it in the future. it's already published with >apache license 2.0. >> >> my proposal would be to place this as additional subprojects below [7] >> >> WDYT? >> >> stefan >> >> >> [1] https://svn. apache.org/repos/asf/sling/trunk/testing/resourceresolver- >mock >> [2] http://wcm.io/testing/sling-mock/usage-mocks.html >> [3] http://wcm.io/testing/sling-mock/usage-content-loader.html >> [4] http://wcm.io/testing/osgi-mock/usage.html >> [5] http://wcm.io/testing/sling-mock/resource-resolver-types.html >> [6] >http://adapt.to/content/dam/adaptto/production/presentations/2014/adaptTo2014 >-Lightning-Mock-AEM&Co-for-Unit-Tests-Stefan-Seifert.pdf >> [7] https://svn.apache.org/repos/asf/sling/trunk/testing >>
