4 Replies Latest reply on Dec 10, 2012 8:08 AM by Michal Matloka

    Unit testing JCR (Modeshape)

    Michal Matloka Newbie

      Is there any reasonable way for testing JCR (Modeshape implementation) like arquillian-extensions-persistence, dbunit etc?

       

      I've found that e.g. jackrabbit has some built in transient repository http://modeshape.wordpress.com/2008/02/22/speedy-unit-testing-with-jackrabbit/

        • 1. Re: Testing JCR (Modeshape)
          Randall Hauch Master

          You can easily test ModeShape in an "embedded" way within JUnit or TestNG. It's actually pretty easy:

           

               ModeShapeEngine engine = new ModeShapeEngine();

               engine.start();

               RepositoryConfiguration config = RepositoryConfiguration.read(...); // from a file, URL, stream, or content String

               javax.jcr.Repository repo = engine.deploy(config);

           

          Note that you can even supply a simple String to the "read()" method, such as "{ 'name':'repoName' }" - the resulting repository will be transient and in-memory but fully-functional.

           

          When you're done, just shutdown the engine:

           

               engine.shutdown();

           

          We do provide two JUnit-based classes in the "org.modeshape:modeshape-unit-test" Maven artifact that your tests can extend, and get automatic management of the repositories and properly configures Infinispan and transactions for in-memory testing. One test is ModeShapeSingleUseTest that works well when each test method should have a clean, fresh repository. The other class is ModeShapeMultiUseTest that starts up a repository that all of your tests will use (e.g., the repository is used in multiple tests). You can see some examples of how those base classes are used here.

           

          If these don't suit your needs, please let us know and we can enhance then or provide additional utilities.

          • 2. Re: Testing JCR (Modeshape)
            Michal Matloka Newbie

            One test is ModeShapeSingleUseTest that works well when each test method should have a clean, fresh repository. The other class is ModeShapeMultiUseTest that starts up a repository that all of your tests will use (e.g., the repository is used in multiple tests). You can see some examples of how those base classes are used here.

             

            I extended this classes. In case of ModeShapeSingleUseTest I can easly override createRepositoryConfiguration method in order tu supply my configuration. However in case of

            ModeShapeMultiUseTest  it is not possible. Methods are static, repository starts with "null" argument, it is not possible to define my config. It would be nice to have method to override like "createRepositoryConfiguration". Or even set method to use (field is private).

            • 3. Re: Testing JCR (Modeshape)
              Randall Hauch Master

              I extended this classes. In case of ModeShapeSingleUseTest I can easly override createRepositoryConfiguration method in order tu supply my configuration. However in case of

              ModeShapeMultiUseTest  it is not possible. Methods are static, repository starts with "null" argument, it is not possible to define my config. It would be nice to have method to override like "createRepositoryConfiguration". Or even set method to use (field is private).

               

              The challenge with the ModeShapeMultiUseTest is that all the setup has to be performed in static methods, which means that there's no way to override the behavior. Perhaps the easiest way to do this is to make the "startRepository()" and "startRepository(RepositoryConfiguration)" methods public so that you can call them directly from your own static "@BeforeClass" methods.

               

              Can you file a JIRA issue for it?

              1 of 1 people found this helpful
              • 4. Re: Testing JCR (Modeshape)
                Michal Matloka Newbie

                Ahh, I tried to solve this without own @BeforeClass methods. When using own @BeforeClass methods I can already call startRepository(RepositoryConfiguration) cause it is protected. So there is no need for it to become public.