Sling
  1. Sling
  2. SLING-1437

GSoC project: create more unit and integration tests for Sling and expand test coverage information

    Details

      Description

      Sling already has fairly good test coverage, but there's always room for improvement.

      The goal of this Google Summer of Code project is to create more unit and integration tests for Sling, as well as measure the test coverage that the combination of unit and integration tests provide.

      Interested students are welcome to get in touch with the Sling community via its developers mailing list to discuss the project, see http://sling.apache.org/project-information.html#mailing-lists

      The student will have to get familiar with the Sling codebase, identify areas where tests are missing, write unit and integration tests and submit the results as patches that the Sling committers can verify and hopefully apply.

        Issue Links

          Activity

          Hide
          Bertrand Delacretaz added a comment -

          Petr's proposal has been accepted, congratulations!

          We can continue to use this ticket for general information about this project, and create more specific tickets as needed.

          One thing that came to mind is that creating integration tests for our main samples (like espblog and slingbucks) would be useful, that can also be done as part of this project if there's enough time.

          Show
          Bertrand Delacretaz added a comment - Petr's proposal has been accepted, congratulations! We can continue to use this ticket for general information about this project, and create more specific tickets as needed. One thing that came to mind is that creating integration tests for our main samples (like espblog and slingbucks) would be useful, that can also be done as part of this project if there's enough time.
          Show
          Petr Shypila added a comment - My proposal for this project: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/ikrumping/5629499534213120
          Hide
          Bertrand Delacretaz added a comment -

          Best is to create pull requests, as both your new tests are in the same module you can just create a new jira ticket for those and mention the pull requests in there.

          Show
          Bertrand Delacretaz added a comment - Best is to create pull requests, as both your new tests are in the same module you can just create a new jira ticket for those and mention the pull requests in there.
          Hide
          Petr Shypila added a comment -

          Hi Bertrand,

          Thanks for update. I've already created unit tests for two classes under /bundles package:
          1. org.apache.sling.jcr.base.SessionProxyHandler - 95% Coverage
          https://github.com/PetrShypila/sling/blob/trunk/bundles/jcr/base/src/test/java/org/apache/sling/jcr/base/SessionProxyHandlerTest.java
          2. org.apache.sling.jcr.base.util.AccessControlUtil - 4%. Coverage. Unfortunately testing other methods is a bit trickier and I need more time to investigate it.
          https://github.com/PetrShypila/sling/blob/trunk/bundles/jcr/base/src/test/java/org/apache/sling/jcr/base/util/AccessControlUtilTest.java

          I plan to provide my proposal on Thursday 26th. In my proposal I will provide links to tests I did and another issue I've found and fixed - SLING-4505. So what is the best way here?
          1. Make a pull request to your repository and provide this link in my proposal.
          2. Just provide links to tests I did, from my forked repository.

          Thanks,
          Petr

          Show
          Petr Shypila added a comment - Hi Bertrand, Thanks for update. I've already created unit tests for two classes under /bundles package: 1. org.apache.sling.jcr.base.SessionProxyHandler - 95% Coverage https://github.com/PetrShypila/sling/blob/trunk/bundles/jcr/base/src/test/java/org/apache/sling/jcr/base/SessionProxyHandlerTest.java 2. org.apache.sling.jcr.base.util.AccessControlUtil - 4%. Coverage. Unfortunately testing other methods is a bit trickier and I need more time to investigate it. https://github.com/PetrShypila/sling/blob/trunk/bundles/jcr/base/src/test/java/org/apache/sling/jcr/base/util/AccessControlUtilTest.java I plan to provide my proposal on Thursday 26th. In my proposal I will provide links to tests I did and another issue I've found and fixed - SLING-4505 . So what is the best way here? 1. Make a pull request to your repository and provide this link in my proposal. 2. Just provide links to tests I did, from my forked repository. Thanks, Petr
          Hide
          Bertrand Delacretaz added a comment -

          It is unfortunately possible that some modules have no tests but I guess we'll concentrate first on the core modules found under /bundles.

          The next step will be to create a setup (maybe on a Sling github fork of yours) that produces a coverage report including both the module's local tests and all tests executed by the launchpad/testing modules, so that we get a meaningful combined coverage report.

          Show
          Bertrand Delacretaz added a comment - It is unfortunately possible that some modules have no tests but I guess we'll concentrate first on the core modules found under /bundles. The next step will be to create a setup (maybe on a Sling github fork of yours) that produces a coverage report including both the module's local tests and all tests executed by the launchpad/testing modules, so that we get a meaningful combined coverage report.
          Hide
          Petr Shypila added a comment -

          I've got a JaCoCo code coverage summary and it looks like some modules under /bundles are not covered with tests at all:

          #bundles/commons
          org.apache.sling.commons.logservice - Code coverage 0%
          org.apache.sling.commons.scheduler - Code coverage 0%
          org.apache.sling.commons.threaddump - Code coverage 0%
          org.apache.sling.commons.threads - Code coverage 0%
          
          #bundles/extensions
          org.apache.sling.bundleresource.impl - Code coverage 0%
          org.apache.sling.discovery.api - Code coverage 0%
          
          #bundles/engine
          org.apache.sling.engine - Code coverage 20%
          
          #bundles/extensions
          org.apache.sling.featureflags - Code coverage 0%
          org.apache.sling.fsprovider.internal - Code coverage 0%
          org.apache.sling.hc.webconsole.impl - Code coverage 0%
          org.apache.sling.models - Code coverage 0%
          org.apache.sling.extensions.webconsolesecurityprovider.internal - Code coverage 0%
          
          #bundles/jcr
          org.apache.sling.jcr.base - Code coverage 0%
          org.apache.sling.jcr.classloader.internal - Code coverage 0%
          org.apache.sling.jcr.jackrabbit.accessmanager - Code coverage 0%
          org.apache.sling.jcr.jackrabbit.server - Code coverage 0%
          org.apache.sling.jackrabbit.usermanager - Code coverage 0%
          org.apache.sling.jcr.registration - Code coverage 0%
          org.apache.sling.jcr.webconsole.internal - Code coverage 0%
          org.apache.sling.jcr.webdav.impl - Code coverage 0%
          org.apache.sling.resourceaccesssecurity - Code coverage 0%
          
          #bundles/scripting
          org.apache.sling.scripting.jsp - Code coverage 0%
          
          #bundles/servlets
          org.apache.sling.servlets.get.impl - Code coverage 13%
          org.apache.sling.servlets.post - Code coverage 16%
          

          I still don't have a clarity of the scope of work to cover all these modules with test, but I think it's a good task improve my skills in unit and integration tests development. So I still want to be applied for this project as a part of GSoC. And my next point is to present some examples of my work.

          BTW: It's also looks like all changes from SLING-1803 are already in trunk. Anyway I have deployed trunk branch with maven jacoco-report profile and it has created for me all reports I need.

          Best,
          Petr

          Show
          Petr Shypila added a comment - I've got a JaCoCo code coverage summary and it looks like some modules under /bundles are not covered with tests at all: #bundles/commons org.apache.sling.commons.logservice - Code coverage 0% org.apache.sling.commons.scheduler - Code coverage 0% org.apache.sling.commons.threaddump - Code coverage 0% org.apache.sling.commons.threads - Code coverage 0% #bundles/extensions org.apache.sling.bundleresource.impl - Code coverage 0% org.apache.sling.discovery.api - Code coverage 0% #bundles/engine org.apache.sling.engine - Code coverage 20% #bundles/extensions org.apache.sling.featureflags - Code coverage 0% org.apache.sling.fsprovider.internal - Code coverage 0% org.apache.sling.hc.webconsole.impl - Code coverage 0% org.apache.sling.models - Code coverage 0% org.apache.sling.extensions.webconsolesecurityprovider.internal - Code coverage 0% #bundles/jcr org.apache.sling.jcr.base - Code coverage 0% org.apache.sling.jcr.classloader.internal - Code coverage 0% org.apache.sling.jcr.jackrabbit.accessmanager - Code coverage 0% org.apache.sling.jcr.jackrabbit.server - Code coverage 0% org.apache.sling.jackrabbit.usermanager - Code coverage 0% org.apache.sling.jcr.registration - Code coverage 0% org.apache.sling.jcr.webconsole.internal - Code coverage 0% org.apache.sling.jcr.webdav.impl - Code coverage 0% org.apache.sling.resourceaccesssecurity - Code coverage 0% #bundles/scripting org.apache.sling.scripting.jsp - Code coverage 0% #bundles/servlets org.apache.sling.servlets.get.impl - Code coverage 13% org.apache.sling.servlets.post - Code coverage 16% I still don't have a clarity of the scope of work to cover all these modules with test, but I think it's a good task improve my skills in unit and integration tests development. So I still want to be applied for this project as a part of GSoC. And my next point is to present some examples of my work. BTW: It's also looks like all changes from SLING-1803 are already in trunk. Anyway I have deployed trunk branch with maven jacoco-report profile and it has created for me all reports I need. Best, Petr
          Hide
          Petr Shypila added a comment -

          The second question, which I've wrote above, is no longer needed.
          As I understand, the implementations of these interfaces are provided by AEM. So on a test phase these classes are not available.

          Show
          Petr Shypila added a comment - The second question, which I've wrote above, is no longer needed. As I understand, the implementations of these interfaces are provided by AEM. So on a test phase these classes are not available.
          Hide
          Bertrand Delacretaz added a comment -

          Please ask on our dev list about those things, preferable one thread per question.

          Show
          Bertrand Delacretaz added a comment - Please ask on our dev list about those things, preferable one thread per question.
          Hide
          Petr Shypila added a comment - - edited

          Bertrand,

          Thank you for your reply. Of course I'm ready to start before GSoC selection starts to show you some examples of my work. I've just forked Sling on Github and have a few questions:
          1. Are there some components on which I should concentrate and investigate more than on other?
          2. Few weeks ago I found a problem with Adaptable.adaptTo() method in a test scope. For example:

          ResourceResolver r = MockSling.newResourceResolver();
          com.adobe.granite.asset.AssetManager a = r.adaptTo(AssetManager.class); //Returns null
          

          And I have same problem with wcm.io library:

          io.wcm.testing.mock.aem.junit.AemContext context = new AemContext();
          ResourceResolver r = context.resourceResolver();
          com.adobe.granite.asset.AssetManager a = r.adaptTo(AssetManager.class); //Also returns null
          

          And I have the pretty same problems with adapting of resources in a test scope. I didn't investigate why yet, but probably I also can do some stuff here?

          Best,
          Petr

          Show
          Petr Shypila added a comment - - edited Bertrand, Thank you for your reply. Of course I'm ready to start before GSoC selection starts to show you some examples of my work. I've just forked Sling on Github and have a few questions: 1. Are there some components on which I should concentrate and investigate more than on other? 2. Few weeks ago I found a problem with Adaptable.adaptTo() method in a test scope. For example: ResourceResolver r = MockSling.newResourceResolver(); com.adobe.granite.asset.AssetManager a = r.adaptTo(AssetManager.class); //Returns null And I have same problem with wcm.io library: io.wcm.testing.mock.aem.junit.AemContext context = new AemContext(); ResourceResolver r = context.resourceResolver(); com.adobe.granite.asset.AssetManager a = r.adaptTo(AssetManager.class); //Also returns null And I have the pretty same problems with adapting of resources in a test scope. I didn't investigate why yet, but probably I also can do some stuff here? Best, Petr
          Hide
          Bertrand Delacretaz added a comment -

          There are no specific priorities between the GSoC projects that I'm looking to mentor, the decisions will be based mostly on the student's potential. Having prior experience with Sling is a plus, so I think it makes sense for you to apply. If you are able to start getting involved in Sling before the GSoC selection starts that's even better.

          Show
          Bertrand Delacretaz added a comment - There are no specific priorities between the GSoC projects that I'm looking to mentor, the decisions will be based mostly on the student's potential. Having prior experience with Sling is a plus, so I think it makes sense for you to apply. If you are able to start getting involved in Sling before the GSoC selection starts that's even better.
          Hide
          Petr Shypila added a comment - - edited

          Very interested in this task as a part of GSoC.
          Have more than a year experience with Sling+Sling models in Adobe Experience Manager 6(and Sling+Slice models in Adobe CQ 5.5). Also have an experience of writing unit tests for aem6 using wcm.io test framework. So it's not new for me.

          Could you please tell me this ticket priority relative to the others(As I understand not all projects will be applied)

          Show
          Petr Shypila added a comment - - edited Very interested in this task as a part of GSoC. Have more than a year experience with Sling+Sling models in Adobe Experience Manager 6(and Sling+Slice models in Adobe CQ 5.5). Also have an experience of writing unit tests for aem6 using wcm.io test framework. So it's not new for me. Could you please tell me this ticket priority relative to the others(As I understand not all projects will be applied)
          Hide
          Bertrand Delacretaz added a comment -

          I have now added the gsoc2015 label to indicate that this project is available for the 2015 edition.

          Show
          Bertrand Delacretaz added a comment - I have now added the gsoc2015 label to indicate that this project is available for the 2015 edition.
          Hide
          Bertrand Delacretaz added a comment -

          If a student has specific skills/interests that match this project we might be able to make it happen in 2012 - best is to contact us via the Sling developer's mailing list, http://sling.apache.org/site/project-information.html#ProjectInformation-lists

          Show
          Bertrand Delacretaz added a comment - If a student has specific skills/interests that match this project we might be able to make it happen in 2012 - best is to contact us via the Sling developer's mailing list, http://sling.apache.org/site/project-information.html#ProjectInformation-lists
          Hide
          Ishan somasiri added a comment -

          Hi,
          Is this still available as a GSoC project..?

          Show
          Ishan somasiri added a comment - Hi, Is this still available as a GSoC project..?
          Hide
          Carsten Ziegeler added a comment -

          In general a gread idea.

          For measuring code coverage in integration tests, it would be cool to have some Sonar integration - the same goes for coverage of script code.

          Show
          Carsten Ziegeler added a comment - In general a gread idea. For measuring code coverage in integration tests, it would be cool to have some Sonar integration - the same goes for coverage of script code.

            People

            • Assignee:
              Unassigned
              Reporter:
              Bertrand Delacretaz
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Development