5 Replies Latest reply on Nov 7, 2007 9:39 AM by porcherg

    db tests infrastructure

    porcherg

      I've looked at the new db test infrastructure. It seems to have been reduced to the minimum: we look for an environment file (with a fixed name) in a directory (given by a java property) and if this file is not found, we take the default resource in the pvm.

      With this test infrastructure, I don't see how we can launch different tests on different configurations without creating multiple directories, with only one environment file in each. More precisely, how can we launch different tests configurations from eclipse in one action ? Was that feature removed to launch only one db test at the time, with the minimal classpath ?

      Moreover, if the file is not found, the resource file is searched from Dbtest's classloader. If we write extensions to the pvm (such as identity) the extension resource is not used (or we have to override methods from DbConfigurationTestSetup). Changing the classloader to the classloader of the current thread fixes this, but maybe this is not the good approach.

      Can we modify this infrastructure to be more flexible ? Configuring the filename from a property can be useful (all test configurations in the same directory).

      I'll try to find a good solution for the classloader (to allow extensions to have their own configuration)

      regards,
      Guillaume

        • 1. Re: db tests infrastructure
          tom.baeyens

           

          "porcherg" wrote:
          I've looked at the new db test infrastructure. It seems to have been reduced to the minimum: we look for an environment file (with a fixed name) in a directory (given by a java property) and if this file is not found, we take the default resource in the pvm.


          exactly. this was the easiest way to get it running in hudson in a way that we saw which configuration is failing. the db matrix project is now testing a combination of JDK's and DB's. currenly only sun's java 5 and postgresql are set up.

          "porcherg" wrote:

          With this test infrastructure, I don't see how we can launch different tests on different configurations without creating multiple directories, with only one environment file in each. More precisely, how can we launch different tests configurations from eclipse in one action ? Was that feature removed to launch only one db test at the time, with the minimal classpath ?


          the problem with that approach is that you get all the test execution reports in one pile. so you can't see which configuration is failing.

          "porcherg" wrote:
          Moreover, if the file is not found, the resource file is searched from Dbtest's classloader. If we write extensions to the pvm (such as identity) the extension resource is not used (or we have to override methods from DbConfigurationTestSetup). Changing the classloader to the classloader of the current thread fixes this, but maybe this is not the good approach.


          can't recall that i used the jbpm test classloader on purpose. i was exactly trying to use the context classloader consistently in the pvm. maybe it was an oversight or there was some reason that i don't remember.

          conclusion you can try to change it, but verify that the tests keep working in IDE, ant and in hudson

          "porcherg" wrote:

          Can we modify this infrastructure to be more flexible ? Configuring the filename from a property can be useful (all test configurations in the same directory).


          what use case do you want to cover ?

          "porcherg" wrote:

          I'll try to find a good solution for the classloader (to allow extensions to have their own configuration)


          in the IDE there are 2 alternatives
          1) change the order of the classpaths in the eclipse project properties. make sure that the configuration file in the extension project is found first.
          2) remove the project dependency on the pvm eclipse project and work with the library in the local repository instead.

          i prefer 1)

          • 2. Re: db tests infrastructure
            porcherg

             

            "tom.baeyens@jboss.com" wrote:
            "porcherg" wrote:
            With this test infrastructure, I don't see how we can launch different tests on different configurations without creating multiple directories, with only one environment file in each. More precisely, how can we launch different tests configurations from eclipse in one action ? Was that feature removed to launch only one db test at the time, with the minimal classpath ?


            the problem with that approach is that you get all the test execution reports in one pile. so you can't see which configuration is failing.


            With the previous test infrastructure, each test setup had a title and the results in eclipse were in a tree-structure (test setup as the root and unit tests as children). The results were easy to read from eclipse.
            For continuous integration, it may be better to have a separate configuration for each test setup.
            For development, it is easier to check directly that the mapping works on different databases before sending a new revision of the mapping files.


            "tom.baeyens@jboss.com" wrote:
            "porcherg" wrote:
            Can we modify this infrastructure to be more flexible ? Configuring the filename from a property can be useful (all test configurations in the same directory).

            what use case do you want to cover ?


            I want to define several test configurations to test locally on different databases and I'd like to store all the configuration files in the same directory.

            "tom.baeyens@jboss.com" wrote:
            "porcherg" wrote:
            I'll try to find a good solution for the classloader (to allow extensions to have their own configuration)


            in the IDE there are 2 alternatives
            1) change the order of the classpaths in the eclipse project properties. make sure that the configuration file in the extension project is found first.
            2) remove the project dependency on the pvm eclipse project and work with the library in the local repository instead.

            i prefer 1)


            Solution 1 worked for me. (so it works from eclipse and ant without changing the classloader)

            regards,
            Guillaume

            • 3. Re: db tests infrastructure
              tom.baeyens

               

              With the previous test infrastructure, each test setup had a title and the results in eclipse were in a tree-structure (test setup as the root and unit tests as children). The results were easy to read from eclipse.
              For continuous integration, it may be better to have a separate configuration for each test setup.
              For development, it is easier to check directly that the mapping works on different databases before sending a new revision of the mapping files.


              I don't expect a lot of problems in the other databases. For me, it's certainly not a must that you test mappings for all the db's.

              In fact, I think it is a good practice to leverage the hudson set up for that. If it works with hsqldb, you can assume it works for all, check it in and a build will be launched automatically.

              You'll hear about it in 3 hours if there was a db related problem. Hibernate does a good job of handling DB compatibility.

              You might want to try locally on a specific database if a hudson configuration failed. That's something that i didn't try yet. But it should be easy i think, with a private config dir just like in the hudson test setup.

              • 4. Re: db tests infrastructure
                tom.baeyens

                Here's something that could be a good compromise: scanning the cfg dir for all cfg.xml files. And create a setup for each of those.

                WDYT ?

                • 5. Re: db tests infrastructure
                  porcherg

                   

                  "tom.baeyens@jboss.com" wrote:
                  I don't expect a lot of problems in the other databases. For me, it's certainly not a must that you test mappings for all the db's.

                  In fact, I think it is a good practice to leverage the hudson set up for that. If it works with hsqldb, you can assume it works for all, check it in and a build will be launched automatically.


                  - Hsqldb uses only read uncommited isolation level, that can be an issue (no locks on database), but maybe Hibernate handles this. I had problems when I tested with JPA because transactions flushed but not committed do not release the lock, so there were problems with postgresql and mysql, but there was no problems with hsqldb.

                  - I tried the mappings with mysql, and the "sequence" generator I used is not supported for mysql. As I cannot access hudson db tests results, this is easier to check directly on some databases.

                  "tom.baeyens@jboss.com" wrote:
                  Here's something that could be a good compromise: scanning the cfg dir for all cfg.xml files. And create a setup for each of those.


                  I tried this solution and after a few adaptations it works for me. Now I can launch tests on hsqldb, mysql and postgresql from eclipse.

                  regards,
                  Guillaume