I have a successfully running suite of integration tests using PaxExam. I run the tests using Maven. The purpose of the tests is to test REST web services implemented through Apache CXF running in Karaf.
The tests run on my machine but fail during Jenkins build due to port conflict. The CXF uses port 8181 which seems to be the default Jetty port. Is there a way to change this port declaratively or programmatically in the tests suite?
I tried using a variety of PaxExam options listed here:
http://team.ops4j.org/wiki/display/PAXEXAM3/Configuration+Options, but to no avail.
Thank you.
Do you use Pax-Exam-Karaf or do you use plain Pax-Exam,
if it's Pax-Exam-Karaf use the following for your configuration:
KarafDistributionOption.editConfigurationFilePut("etc/org.ops4j.pax.web.cfg",
"org.osgi.service.http.port", "alternative-port"),
if it's plain Pax-Exam:
systemProperty("org.osgi.service.http.port").value("8181")
You might also take a look on how Karaf does it's regression testing at Karaf Regression Test or take a look at the pax-web itests at Pax-Web Integration Tests
Related
I am having an Angular2+ application.
I have done some unit testing with Karma-Jasmine. But my assumption is that this is only for dev enviroment(pre production).
I am looking for a testing framework through which the "dist" folder build can be verified(components, web services, etc...)? so that once the build is taken, some script that do login, should able to verify the response object for login service etc...
Sounds like you are asking how to do end-to-end testing to your application in addition to unit tests. In that case Selenium and more modern Cypress are what you are looking for.
I have a Django Project. I want to make end-to-end tests for it using Selenium.
It interacts with Other components (usually run through docker-compose) API and functions properly.
The Django Project and 'Other Components' are different repositories (obviously there are multiple 'other components')
Testing of parts that don't involve API calls, have been tested.
You can use a continuous integration like Jenkins to do your automated task like Selenium.
It's really easy to install localy and/or to serve.
How to install Jenkins : here
have a great day!
Hi I am trying to get code coverage for my web application.
I Instrumented my compiled classes then I deployed it in jetty server.
then i ran my test cases from http client and i was expecting cobertura.ser file to be generated at server but it is not generated when I stop jetty server.
please let me know how can i get code coverage for web application from jetty.
I'm using java 1.7
I am not using maven.
I followed the steps based on below link.
Java: measure code coverage for remote scripting tests .
This is probably due to the fact that Cobertura dumps coverage data when the VM exits, not when the server stops.
You can have a look at the alternative maven plugin I wrote for Cobertura and its companion example project:
https://github.com/QualInsight/qualinsight-mojo-cobertura
https://github.com/pawlakm/qualinsight-mojo-cobertura-example
The documentation provided by the first link describes how to configure Jetty and with a small extension that dumps coverage data during server stop (see "Gathering IT test coverage data when running instrumented code on Jetty") This documentation is for Jetty 9.3, however the second link provides running examples for Jetty 7.6, 8.1, 9.2 and 9.3.
In your context, you should use wartest-jetty9.2.x module as it aimed at Jetty 9.2.x and JDK1.7. Have a look at the module's (and its parent) pom.xml file, as well as jetty.xml file
Do not hesitate to give feedback and ask questions, I'll do my best to help you.
Regards,
I've got jsTestDriver up and running, and I use jstd-maven-plugin to run the tests during a build.
The plugin needs a browser to be specified in order to work though, and I'd like to use something like rhino or htmlunit that won't actually launch a browser.
The jasmine-maven-plugin does this with htmlunit, and works quite well.
Is there a way to specify a headless browser for jstd-maven-plugin?
One of the reasons that I prefer JsTestDriver over other JavaScript testing frameworks, is that the tests are made on real browsers, and allows me to test on all the major browsers that consumes my application, and verify compatibility issues with older versions of IE for example.
If you prefer to run a complete headless JavaScript testing server, perhaps JsTestDriver is not your best choice. I think CasperJS is a very good alternative to achieve that. It uses PhantomJS, a scriptable headless WebKit engine to run the tests.
In my case, I have a complete headless server running an instance of JsTestDriver, and Other server whit a couple of virtual machines, with common SO/Browsers combinations (Windows/IE7; Windows/IE8; Linux/Firefox...), which have actual browsers connected to the headless JsTestDriver server. But if you don't need to use real browsers, the CasperJS alternative may be a good choice.
JsTestDriver need a browser to run the javascriptcode. So there is no way to run your tests without a browser.
There is a way to open the browser in a virtual monitor. This is described in this question:
Run Headless JsTestDriver?
JSTD maven plugin can be extended to run phanatomjs.
I have a maven project.
I want to test (spring) controller class and also wrote a test class.To successfully run this test class,I want the web app to be deployed in the (jetty )server.
How I can achieve this, when I execute maven clean install.project is
built->deployed to server->start server->run test->stop server
I have been looking at jetty plugin and cargo plugin but still finding it difficult to do what I want.
If you want to unit test your spring controllers, you do not need to have your web application deployed to jetty. Spring framework has testing support as documented here.
There are many examples in the web. You can also refer to the test classes here which uses testNG.
If you do want to run tests in jetty, then refer to these instructions. Essentially you would bind the jetty start and stop to pre-integration-test and post-integration-test phases.