i have a following problem.
I'd like ti test my JSF Application with JSFUnit.But JSFUnit supports inly junit3 (all our unit tests run with JUnit4).
Is it possible to include in pom.xml two junit dependencies (junit4 and junit3) with e.g. different scopes?
Please help and thanx in advance
If you separate the project into two submodules, one which needs JUnit3 and the other which needs JUnit4, you can specify the test dependencies separately in the child pom.
As Péter said, you should split your project in separate modules. In cases like this I've also seen the use of dedicated test modules turn out good results.
This way the JUnit4 test dependency you have in foo-web is not visible to the tests running from foo-web-jsf-tests.
Related
I am new to automated testing. I am trying to set up a Maven project for my Selenium test automation work. I put all the packages pertaining to envVariables, library, settings, resultLog, errScreenshots etc under src/test/java.
I have a couple of questions here
i)I showed this framework to my developer and he asked me to move some of the packages under src/test/resources. I am not sure whether this needs to be done or whatever I have configured is correct. If I need to move the packages to resources folder, what packages should I move? Can somebody please advise me on how to configure this?
ii) what should the src/main/java folder contain? I thought it will contain the src code of my application and test folder would contain unit tests and selenium tests. But my developer says the test folder will contain only unit test that test the classes in the src/main/java. It should not contain my selenium tests. Can somebody please explain this to me?
Regards
vasu
I am not sure about the structure of your automation project. I prefer the following hierarchy in MAVEN projects
src
|-----main
| |-----java
| |-----Pages (contains application code arranged as one Class per Page)
| |-----Steps (calls the page objects and methods called in Pages)
|-----test
|------java
| |-----Test (Opens browser and calls steps to perform test - TestNG)
|------resources
|-----InputSheets
|-----Environment Variables
The results are saved in C or D drive and are time stamped to avoid getting overwritten.
The automation helper library is created as a separate Maven project and is added as a dependency to the test project. In this way the helper library is independent from the test project and can be used across all projects if need arises.
All this being said, much of the structure is a matter of choice and varies according to your project requirements.
"src/main/" is for production code or test automation framework, not for test cases. "src/test/" is for testing stuff, including selenium tests. "java" folders are for classes, "resource" folders are for configuration and test data.
I suggest creating a separate maven module for your testing stuff: test framework and test cases.
Please refer maven directory layout page for more information.
UPDATE: I have created sample maven project to show how run selenium test with selenide.
I am following this article: http://www.softwarepassion.com/it-coverage-with-arquillian-jacoco-extension/ to get test coverage for arquillian integration tests. My project is a multi module though and I don't know where to put the plug in and dependencies. Is it in the top pom, the artifact-making module or in the integration test module?
Thank you
To some extent it depends on the details of your Maven setup, which aren't in your question. Here is some general advice.
1) Where should you put the arquillian-jacoco and jacoco dependencies?
These dependencies should probably go wherever the rest of your Arquillian dependencies are. My understanding is that it is simply having these dependencies that triggers Arquillian to use JaCoCo, not the plugin declaration; even if these dependencies are in a parent of the POM with the actual Arquillian tests, the Arquillian test classes should still be instrumented. You wouldn't put these dependencies in a sibling module to the module with the tests though as they need to be inherited by the integration test module (unless this sibling module has been declared as a dependency of the test module of course).
2) Where should you put the JaCoCo plugin declaration?
As noted above, you may not even need this declaration, depending on what you are trying to achieve. If you want to generate a report, rather than just the jacoco.exec files, then you will need to declare the plugin and an execution with the report goal. You may also want to declare the plugin with the prepare-agent goal if you have other tests that you wish to be instrumented with JaCoCo, such as unit tests.
If you are going to declare the plugin, it can be treated the same way as any other Maven plugin. If you want to run JaCoCo across multiple modules by default you could choose to put the plugin declaration in your parent POM within the regular 'plugins' tag and have it inherited by all child modules, or you may wish to put it in the parent POM within the 'pluginManagement' element so the configuration can be inherited (see http://maven.apache.org/pom.html#Plugin_Management). Alternatively, if you only want to run Arquillian tests in your integration test module, you could also simply declare the plugin in this module's POM (given that you want a report, and without the prepare-agent goal if you're only instrumenting Arquillian tests).
Hope that helps!
I have Selenese with maven and testSuite with a lot of tests, my question how to run some of test cases?
Just like running any specific test in maven:
mvn test -Dtest=(YOUR_TEST_CLASS_NAME)
You can also supply test=TEST_CLASS* for all of that type, etc. Maven has some pretty good name and package matching. You may even be able to run a single test method by supplying the method name (although I have not tried this).
Check the Selunit maven plugin out, it provides include and exclude filters for Selenese suites in the pom.xml configuration.
I'm developing a Solr plugin and using the Solr test-framework I place a test SOLR_HOME dir under test/resources with /conf/ and /lib . Now the framework inistantiates a SolrCore and loads my plugin from /lib. Not an issue to output the jar of the plugin to /lib, but the issue is that the plugin is not yet available since it still needs to past the test (chicken and the egg).
How do you recommend solving this? I see those options:
Create another project for the tests with a dependency on the plugin, and in it run the tests. Simple enough, but how do I ensure that everytime the plugin is built also the tests of this other project is built? The point of the automated tests at every build is to having a new plugin jar which breaks the tests.
In dp4j pom.xml I build the project on 2 phases, in the 1st I <include> only the annotation processors while in the other I compile the tests which rely on the annotation processors compiled in the eariler phase.
I'm in favor of 2 since copy-pasting the configuration doesn't seem a bad option, and makes it seem less complicated than it probably is. I don't remember if I had asked about it here - what do you recommend? Any other case studies /working code to look at?
there's a 3rd. most probably best solution ~ do nothing!
I was under the impression that the Solr Testframework need to load my plugin from /lib but apparently it doesn't need to, it can load it from test-classes, all on its own!
I'd like to run my JUnit tests in JMeter. Using maven-jar-plugin I can create a jar with my tests in order to put it inside the JMeter's classpath ($JMETER_HOME/lib/junit). The problem is that my tests have a lot of dependencies that Maven2 doesn't put into the jar, including the main classes of the project, classes from other projects and external libraries. How can I do this?
You can use the fatjar plugin.
As iwein has mentioned, you may use the maven-fatjar-plugin which will put all the dependent JAR's inside of your JAR artifact and create the appropriate MANIFEST entries to include them on your classpath.
Another option is that you can use the maven-shade-plugin which will simply take all of the ".class" files out of the dependecy JARs and include them directly in your JAR. This is called a UBER-JAR. There are a couple of reasons which I prefer this approach:
This often leads to slightly smaller JARs
I have other plugins which already manipulate the MANIFEST (including the Classpath property) and I don't want to chance having an incorrect manifest being generated.
Creating an UBER-JAR is just too good to pass up ;)