Single deployment for all test cases in Arquillian - jboss7.x

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?

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.

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?).

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:-)

Related

JUnit5 Jupiter test terminated in IntelliJ

When I run the my unit tests, they immediatly are being terminated. However no logging is presented. (only 'Failed to start' and 'Process finished with exit code 255').
Tests worked before...
JUnit 4 does not give me this problem.
Test do run succesfully in Maven.
I use JUnit5 Jupiter and IntelliJ IDEA 2020.1 (Ultimate Edition).
Anyone any thoughts?
I was experiencing the same behaviour as described in this question. What fixed the problem for me was removing conflicting dependencies:
Remove similar entries ->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.2.0</version>
</dependency>
as it is already included by spring-boot-starter-test. Removing the explicit dependency will enable SpringBoot to handle incompatible version issues between dependencies for you.
#Before and #After no longer exist; use #BeforeEach and #AfterEach instead.
#BeforeClass and #AfterClass no longer exist; use #BeforeAll and #AfterAll instead.
https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4-tips
I just had the same issue.
The single thing that fixed this - and which I could reproduce - is this:
don't .close() System.out (or System.err).
#Test
void failure()
{
System.out.close();
}
makes happen what you describe.
Wherever I passed System.out to functions that would .close() their OutputStream later, I replaced them with a new ByteArrayOutputStream() instead.
After experiencing the same, I've debugged only to find that tests are completely executing and all assertions pass.
I've managed to narrow the issue down to System.out.println call whose output is somehow being held until all the tests are complete before, and eventually flushed, before IDEA gets to claim that test was interrupted.
Removing a reference to System.out from test code makes the tests go green in IDEA again.
For me using #BeforeEach and #AfterEach worked instead of #BeforeAll and #AfterAll

Extent Report plugin not working with testng + cucumber

I have a complex problem, please read -
I wanted to run the extent report with my framework which is created using cucumber, testng and java.
I am running the testng file to run the test class file which will eventually run the #CucumberOptions and features added in it.
My test class is extended with AbstractTestNGCucumberTests to support testng with cucumber.
Now everything is working fine. basic testng report is getting generated.
note : I am running some tests parallel and they are also working fine.
Now i wanted to implement the extent report in my framework. Can you tell me how to do it using plugin which which add the logs same as the cucumber statement added in the feature file.
ps : I have gone through some link which shows me how to run the extent report with junit using #AfterClass, but how to use this with testng.
What I have tried -
libraries used - com.aventstack --> extentreports and com.vimalselvam --> cucumber-extentsreport
Error - cucumber.runtime.CucumberException: Couldn't load plugin class: com.vimalselvam.cucumber.ExtentCucumberFormatter
used plugin - plugin = {"com.vimalselvam.cucumber.ExtentCucumberFormatter:output/report.html"}
and code added under #AfterTest is : Reporter.loadXMLConfig(new File("xml path")
PLEASE HELP !!!
I wanted to generate extent report which will also support parallel execution.
If you want to run test cases in parallel and want to have stable extent report, please go for cucumber 4.x.x version and there are 2 ways of implementing extent report in Cucumber
1. Using Cucumber-JVM 4 adapter for Extent Framework(extentreports-cucumber4-adapter) & below are the steps to implement - (Beauty - You do not need to write any code any where to generate report this way except from setting adapter in runner below)
Add adapter dependency under POM.XML
<dependency>
<groupId>com.aventstack</groupId>
<artifactId>extentreports-cucumber4-adapter</artifactId>
<version>1.0.6</version>
</dependency>
Add the com.aventstack.extentreports.cucumber.adapter.ExtentCucumberAdapter plugin to the runner.
#RunWith(Cucumber.class)
#CucumberOptions(plugin = {"com.aventstack.extentreports.cucumber.adapter.ExtentCucumberAdapter:"})
public class RunCukesTest {
// ..
}
Report Output Directory - ../Project Directory/test-output/HtmlReport
2. Adding aventstack dependency under POM.XML
<dependency>
<groupId>com.aventstack</groupId>
<artifactId>extentreports</artifactId>
<version>3.1.5</version>
</dependency>
In this workflow, Do not Add the com.aventstack.extentreports.cucumber.adapter.ExtentCucumberAdapter plugin to the runner.
I assume you are using cucumber-extentsreport.*.jar as dependency.
You must specify the extent properties #beforesuite method.
ExtentProperties extentProperties = ExtentProperties.INSTANCE;
extentProperties.setReportPath();
you will also need to add plugin - com.cucumber.listener.ExtentCucumberFormatter:

Reading extra properties or host addresses inside the JSON test case

I am using zerocode-rest-bdd maven lib with following version. I have my applications host and port defined in the JUnit runner with "#TargetEnv("app_host.properties")".
<dependency>
<groupId>org.jsmart</groupId>
<artifactId>zerocode-rest-bdd</artifactId>
<version>1.2.15</version>
</dependency>
I want to access more hosts/ports(boundary application IPs) and common tokens(SAML, OAuth etc) into my JSON test case which I am unable to access using ${{app_host}}.
Is there any other way to extend or configure these extra properties so that I can access them and validate my boundary contracts?
app_host.properties contains:
web.application.endpoint.host=https://api.github.local
web.application.endpoint.port=443
web.application.endpoint.context=
#Can not access these below properties
app_host_1=https://app1.host.local.uk
saml_token=<SAML>sdf-wer</SAML>
Accessing in the test case as below:
"url": "${app_host_1}/users/u123",
Seems like you are using an older version of Zerocode lib. You can update to <version>1.2.17</version> or to the latest as below.
<dependency>
<groupId>org.jsmart</groupId>
<artifactId>zerocode-tdd</artifactId>
<version>1.3.x</version>
</dependency>
Then, once you define your properties e.g.
micro_host_1=https://micro.host1.local.uk
xyz_key=abc_value
the values can be resolved via ${micro_host_1} or ${xyz_key} to, https://micro.host1.local.uk or abc_value respectively in the test cases.
Hope this helps!

SwaggerContextService class not found in swagger-jersey2-jaxrs maven artifect

I have multiple Resource class and i don't know if i can use #SwaggerDefinition in all of them so i am trying to write a custom bootstrap servlet
I am fallowing the example in the fallowing link
Bootstrap for swagger-jersery2
and i am not able to find SwaggerContextService class in any package .
So i tried
BeanConfig beanConfig = new BeanConfig();
beanConfig.configure(swagger);
even that is not working
My maven dependency looks like this
<dependency>
<groupId>io.swagger</groupId>
<artifactId>swagger-jersey2-jaxrs</artifactId>
<version>1.5.0</version>
</dependency>
can some one help me with this
It looks like you are using a much older version of swagger. SwaggerContextService was added in 1.5.7 and the latest stable version is 1.5.13.

DRY way of defining dependencies for both jetty:run and deployment

I'm wrapping up the build for a web project which supports two ways of running:
locally using mvn jetty-run;
deployed on an application sever.
For the application server many libraries are marked as provided, since otherwise classpath conflicts occur. At the same time, I have redeclared these dependencies as compile dependencies for the jetty-maven-plugin, since otherwise the goals does not run properly.
The build works like this, but I have a large number of duplicated libraries. Is there a cleaner way of doing this?
Just to follow up on this JETTY-429 has been merged so you can with caution add a configuration parameter <useProvidedScope>true</useProvidedScope>. This will included the provided dependencies on the jetty plugin classpath.
It is worth reading JETTY-429 for details on the potential issues using this option can bring.
Well there's always the wicket solution. (It doesn't have to do anything with wicket, but it can be found in the wicket maven archetype.)
Use a main class that starts jetty programmatically with the project as webapp context. This should pick up all maven dependencies even in provided scope on all major IDEs. Here is such a class:
public class Start{
private static final Logger LOG = Logger.getLogger(Start.class);
public static void main(final String[] args) throws Exception{
LOG.addAppender(new ConsoleAppender(new SimpleLayout(), "system.out"));
final Server server = new Server();
final SocketConnector connector = new SocketConnector();
// Set some timeout options to make debugging easier.
connector.setMaxIdleTime(1000 * 60 * 60);
connector.setSoLingerTime(-1);
connector.setPort(9090);
server.setConnectors(new Connector[] { connector });
final WebAppContext bb = new WebAppContext();
bb.setServer(server);
bb.setContextPath("/");
bb.setWar("src/main/webapp");
server.addHandler(bb);
try{
LOG.info(//
">>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP" //
);
server.start();
System.in.read();
LOG.info(">>> STOPPING EMBEDDED JETTY SERVER");
server.stop();
server.join();
} catch(final Exception e){
LOG.error("Something bad happened", e);
System.exit(100);
}
}
// CHECKSTYLE:ON
}
The nice part: you can launch this as a standard eclipse run configuration, including easy debugging.
The downside: you need jetty as an additional provided dependency:
<!-- JETTY DEPENDENCIES FOR TESTING -->
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-util</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
I'm not saying this is the best solution, but how about doing this:
Your default dependencies list the provided dependencies as "provided". The default project configuration should produce WAR files which are going to run on non-Jetty servers.
Define a profile "jetty" and redeclare the provided dependencies in the compile scope. Then just run mvn -Pjetty jetty:run
It might not be the cleanest solution in the world, as it forces some repetition, but it should get the job done for you.
I'd also like some kind of flag to be able to include provided scoped dependencies when running Jetty. Actually, Jetty already has a useTestClasspath doing something similar for test scoped dependencies (why not including provided dependencies in that case) in order to avoid having to duplicate dependencies in a profile. This is tracked by JETTY-429 which has a patch for such a flag.