6 Replies Latest reply on Aug 30, 2012 5:41 PM by jfrenetic

    Arquillian persistence ext alpha-4 - Cleanup by default, script path

    ringerc

      Hi folks

       

      I've just given the Alpha 4 release of the Arquillian Persistence Extension a go to see if it'll help simplify my database tests. After initial testing I have a few comments and questions.

       

      Most importantly, is it really a good idea to have the database "cleaned" by default? Deleting from all tables does not, to me, conform to the principle of least surprise. If you want a temporary DB you're often using an in-mem h2 or something anyway. More importantly, it's a really unsafe default, especially because a mistake in supplying a datasource could have very nasty results. Sure, your test environment should be completely separate to your production env with no risk of data loss, but in reality not everyone's going to set it up that way. I think this default should be changed as a matter of urgency before 1.0.

       

      One thing I noticed in the docs: it took me a while to correctly place my @ApplyScriptBefore and @ApplyScriptAfter . The docs just said the "scripts" directory; this turns out to be "scripts/" on the classpath of the deployed archive, ie src/test/resources/scripts . I've submitted an edit to make this more explicit.

       

      For some reason my tests don't appear to see/respect the defaultDataSource in arquillian.xml (src/test/resources/arquillian.xml). This config still results in an exception thrown by seam persistence, complaining that the datasource isn't provided.

       

      <?xml version="1.0" encoding="UTF-8"?>
      <arquillian xmlns="http://jboss.com/arquillian"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      
         <extension qualifier="persistence">
             <property name="defaultDataSource">java:/datasources/some-test-ds</property>
             <property name="userTransactionJndi">java:jboss/UserTransaction</property>
             <property name="alwaysExcludeFromDataSetsComparision">id</property>
         </extension>
      
         <container qualifier="jboss7remote" default="true">
             <configuration>
                 <property name="managementAddress">127.0.0.1</property>
                 <property name="managementPort">9999</property>
             </configuration>
         </container>
      
      </arquillian>
      

       

      Tests fail with:

       

      org.jboss.arquillian.persistence.exception.DataSourceNotDefinedException: DataSource not defined! Please declare in arquillian.xml or by using @DataSource annotation.

       

      I've tried adding arquillian.xml to my ShrinkWrap archives (WarArchive format) using addAsResource( ) and addAsWebInfResource( ) as I wasn't sure where arq would be looking for the config within a deployed archive. Neither had any effect. Ideas?

        • 1. Re: Arquillian persistence ext alpha-4 - Cleanup by default, script path
          jaikiran

          The arquillian.xml isn't expected to be packaged in the test archive. It's just expected to be on the root of the test classpath (on the client side). So typically, in a Maven project, it's expected to be in src/test/resources/ folder of the project.

          1 of 1 people found this helpful
          • 2. Re: Arquillian persistence ext alpha-4 - Cleanup by default, script path
            ringerc

            Interesting. Arquillian is finding arquillian.xml and using the container definitions within it successfully, but arquillian persistence doesn't seem to be using the extension parameters from it. I might have to go source-diving.

            • 3. Re: Arquillian persistence ext alpha-4 - Cleanup by default, script path
              bmajsak

              Hi Craig,

               

              first of all many thanks for improving the docs!

               

              With regards to arquillian.xml it's assumed to be available in the classpath whether it's src/test/resources or any other directory which then maven can include [like it's done for integration tests where I'm using different profiles with different APE settings]. On the other hand it's quite strange that extension itself does not pick up settings by default. It should use qualifier attribute. Is it possible that you might have more than one arquillian.xml file in your classpath while running tests?

              Craig Ringer wrote:

               

              Most importantly, is it really a good idea to have the database "cleaned" by default? Deleting from all tables does not, to me, conform to the principle of least surprise. If you want a temporary DB you're often using an in-mem h2 or something anyway. More importantly, it's a really unsafe default, especially because a mistake in supplying a datasource could have very nasty results. Sure, your test environment should be completely separate to your production env with no risk of data loss, but in reality not everyone's going to set it up that way. I think this default should be changed as a matter of urgency before 1.0.

              I strongly believe that principle to run each "db-related" test in isolation is worth to follow - meaning you always start with clean state and provide all necessery data using sql or data sets. You can easily turn it off if you really need either by using @Cleanup annotation for given test or test class or (available in master, to be release in Alpha 5 this week) in arquillian.xml. Messing up with your production db must be with extra cause and there you should really configure tests in a way to avoid problems.

               

              Additionaly you can also say what kind of cleanup should be performed, namely:

              STRICT

              Cleans the entire database. This strategy might require turning off database constraints (e.g. referential integrity).

              USED_ROWS_ONLY

              Deletes only those entries which were defined in data sets used for seeding.

              USED_TABLES_ONLY

              Deletes only those tables which were used in data sets.

              1 of 1 people found this helpful
              • 4. Re: Arquillian persistence ext alpha-4 - Cleanup by default, script path
                bmajsak

                Have you tried to have container definition before extension element?

                • 5. Re: Arquillian persistence ext alpha-4 - Cleanup by default, script path
                  ringerc

                  I'll have to do some more testing re arquillian.xml, try re-ordering the clauses and examine the created test archive to see where exactly it lands up. I'll get back to you.

                   

                  I see your point re cleanup - if your tests are misconfigured so they are crapping all over a database you care about, you've already got problems. Deleting everything from the tables just makes it more obvious and prevents any data mangled by running unit tests against it from being accidentally preserved. Fair enough. I suspect a few people are going to get bitten by accidentally running tests against a DB they care about, but that can happen with or without arquillian persistence and isn't its problem. Forget I said anything, my reasoning was poor.

                  • 6. Re: Arquillian persistence ext alpha-4 - Cleanup by default, script path
                    jfrenetic

                    I've also had some hard time, when I forgot to use @Cleanup annotation And I also doubt that cleaning the entire database is a reasonable default. I think there should at least be some SCHEMA filter, because when run on Oracle, for example, it also tries to clean up even system tables, which is obviously wrong.