CODEWITHSUNDEEP
jboss7.xjboss-arquillian
Ranu Jain
Ranu Jain

Reputation: 577

Single deployment for all test cases in Arquillian

We are using arquillian-junit-container 1.0.0 final version for Junit Test.

We have so many test classes and every test class as @Deployment method so when i run all test together then its creating issue of memory and performance.

Can anyone help me to sort out this issue by telling how we can avoid multiple deployment for each single class. How we can achive Single deployment for all test cases in Arquillian?

Upvotes: 21

Views: 8226

Answers (3)

Ryan Bennetts
Ryan Bennetts

Reputation: 1183

You can't, officially, yet.

The JIRA issue ARQ-197 was created to support running multiple tests classes against a single deployment. In 2010! If you want this feature, please vote for it.

This is Arquillian's most voted for issue. It's currently slated for version 2.0.0.CR1, which might be the next version, but I can't find a roadmap / release plan anywhere which confirms this.

In the meantime, there is the Arquillian Suite Extension (latest incarnation is here). It's not official, and so there are limitations, but the original codebase was written by one of the Arquillian core developers to prove they could eventually support JUnit suites. The issue to make this support official is here and is Arquillian's second-most voted issue.

Upvotes: 10

Petr Mensik
Petr Mensik

Reputation: 27496

Why should you have deployment method in every class?I use Arquillian for functional testing with Drone and Graphene and I have one base class with deployment method, initialization of Selenium Web Driver, few utils methods and my every other test class is just extending this class and reusing my Web Driver instance.

I don't see why shouldn't this work in your case (or even without extending the base class).

Ok, this is how it looks

public class WebDriverTest extends Arquillian { //I am using TestNG

    @Drone
    protected WebDriver driver;

    @ArquillianResource
    private URL contextRoot;

    @Deployment(testable = false) //functional tests cannot run in container
    public static WebArchive createDeployment() {
        File archive = new File("target/myApp.war");
        ShrinkWrap.createFromZipFile(WebArchive.class, archive);
    }
}


public class TestClass extends WebDriverTest {

    @Test
    public void test1() {}

    @Test
    public void test2() {}
}

Everything is working fine here. Also make sure that you have right Maven dependencies, these has to be present in order to run functional tests (then make dependency for anything you need from these BOMs)

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.arquillian.selenium</groupId>
            <artifactId>selenium-bom</artifactId>
            <version>${selenium.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-bom</artifactId>
            <version>${arquillian-core.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.arquillian.extension</groupId>
            <artifactId>arquillian-drone-bom</artifactId>
            <version>${arquillian-drone.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

EDIT

Ok, so according to this JIRA you won't see this feature in Arquillian until version 2.0.0.CR1. So the code I mentioned above is the best you can get right now:-)

Upvotes: 0

DJ Spiess
DJ Spiess

Reputation: 993

I think you're asking why does Arquillian need to deploy a new war for each test class when you run the test. I have the deployment method as Petr Mensik describes, but each test class will still deploy in it's own war when you run the tests. Putting it in the super class only simplifies the code from a less lines perspective. It will mean that every test class that is sub class will have the same deployment. That means your deployment will be the super set of dependencies, and thus much larger than doing it individually. I think it's easier to manage, and worth the price especially with larger projects.

To answer your question, it looks like you will not be able to group your tests and deploy one war to test until version 2.0 (due out at the end of this year?).

Upvotes: 2

Related Questions