5 Replies Latest reply on Feb 21, 2012 4:53 PM by Bartosz Majsak

    How  to execute @Before* methods in container?

    Rich DiCroce Novice

      I'm running Arquillian 1.0.0.CR7 with JBoss 7.1.0.Final and TestNG 6.4. I'm trying to add DBUnit to my testing stack so I can test some JPA stuff, so I'm trying to add a @BeforeClass method to my test class to set up the database with the appropriate test data. I would prefer to have DBUnit get a connection through a JNDI lookup (thus ensuring that DBUnit and the deployed code are looking at the same database), but all of the @Before* annotations seem to cause the method to be run on the client. Is there a way to force those methods to run in the container instead?

        • 1. Re: How  to execute @Before* methods in container?
          Bartosz Majsak Master

          Hi Rich,

           

          I would suggest to have a look at Arquillian Persistence Extension which does all what you need but saves you from dealing with DBUnit setup. Just bunch of annotations, data sets in your format of choice (XML, Excel, YAML or JSON), a bit of configuration (have a look at arquillian.xml in int-tests module on in showcase) and you are done.

           

          I'm currently working on Alpha4 release which will bring bunch of fixes and improvements. Should be available in next few days. Before that just wanted to point you to the problem which you might encounter - https://issues.jboss.org/browse/ARQ-752

           

          If you will face any other issues please open a thread here and I'll be more than happy to help!

           

          Cheers,

          Bartosz

          • 2. Re: How  to execute @Before* methods in container?
            Rich DiCroce Novice

            Hi Bartosz,

            I just spent the last 2.5 hours trying and failing to get Arquillian Persistence to work.

             

            My main problem revolves around https://issues.jboss.org/browse/ARQ-718, which (probably) prevents me from using a DBUnit flat XML file. I'm using Jailer to extract a subset of production data, and many tables have the possibility that various columns are null. Since column sensing isn't enabled and Arquillian Persistence provides no way to enable it, DBUnit throws a ton of warnings saying certain columns will be ignored because the first appearance of a record for a table didn't contain those columns. I could try generating a DTD to work around that problem, but those warnings are then followed up by some more warnings saying that "The configured data type factory 'class org.dbunit.dataset.datatype.DefaultDataTypeFactory' might cause problems with the current database 'Microsoft SQL Server'". On top of that, I know MSSQL doesn't allow INSERTs with values specified for autoincrement columns, so unless Arquillian Persistence is detecting that somehow and configuring itself appropriately, I need to be able to set the DatabaseOperation to one of the InsertIdentityOperation choices. An initStatement isn't good enough to work around this, because MSSQL only allows you to SET IDENTITY_INSERT <table> ON for one table at a time (i.e. you can't set it for the whole database and you have to SET IDENTITY_INSERT <table> OFF before doing SET IDENTITY_INSERT <next table> ON).

            In any case, I really don't want to have to manually edit the data file, so I tried exporting to straight SQL and using @UsingScript instead of @UsingDataSet. This doesn't work either. The script generated by Jailer works fine if I run it manually (it's smart enough to put in the SET IDENTITY_INSERT statements when needed), so the script itself isn't the problem.

             

            With either method, the database is never filled (with method one, even tables that don't have autoincrement identity columns or any foreign keys, that DBUnit shouldn't have a problem loading, are still empty). I don't know why, because nothing appears in the logs, and Arquillian even claims my test completed successfully when it was obviously never even run. Any idea as to what's happening here? Or should I just wait for Alpha4 and try again?

            Also, you should bump shrinkwrap-extension-descriptors to a newer version. The version you're currently using has a transitive dependency on shrinkwrap-descriptors-api version 0.1.4, which conflicts with and overrides version 1.1.0-beta-1, which is a transitive dependency needed by arquillian-testng-container. I had to add some stuff to my POM to force 1.1.0-beta-1, because otherwise I was getting MethodNotFound exceptions before the server even started.

            Rich

            • 3. Re: How  to execute @Before* methods in container?
              Bartosz Majsak Master

              Hi Rich,

               

              I'm sorry to hear that APE is giving you a hard time. In Alpha3 in fact there is an issue with column sensing and nullability, both already pushed to master. With regards to DefaultDataTypeFactory it will be configurable as part of ARQ-718.

               

              Many thanks for invaluable feedback with regards to MS SQL insert issue and Shrinkwrap descriptors! Already opened JIRA for that (ARQ-764, ARQ-765).

              Thanks to early adopters like you I have a chance to improve extension based on diverse, real-life use cases. I will let you know once Alpha4 will be available.

               

              Cheers,

              Bartosz

              • 4. Re: How  to execute @Before* methods in container?
                Rich DiCroce Novice

                Hi Bartosz,

                Thanks for the response! Looking forward to Alpha4, and especially looking forward to ARQ-718 getting implemented. I discovered that DBUnit disables batched statements by default, and enabling them cut the load time by about half!

                 

                Until those issues get resolved, I have discovered a workaround (without APE), which I'll document here in case anyone else is in the same boat. The trick is to define a @Test method (I called it "setup") that initializes the database, then annotate all of your real tests with @Test(dependsOnMethods = "setup"). That way, the setup method gets run in the container, and all of the real tests don't execute until after it finishes. It's a disgusting, ugly hack, and it's not very flexible either. I'm definitely looking to switch over to APE in the future, but it works for now.

                 

                Rich

                • 5. Re: How  to execute @Before* methods in container?
                  Bartosz Majsak Master

                  Please go ahead and document it I think it might be also useful for APE itself. If you have any suggestion what should be improved feel free to create "feature request" in JIRA. I've also create "Roadmap Thread" to discuss what would be useful in next releases of APE. If you have anything in mind I will be extremely happy to see it.