Are you supposed to run automated integration tests against a QA server or are you supposed to somehow start an application server from your tests? Does anyone do option #2? How are you supposed to start an application server from tests?
I'm just running into the dilemma of not knowing where to point my selenium driver to. This is a spring java app.
Are you supposed to run automated integration tests against a QA
server or are you supposed to somehow start an application server from
your tests?
As a practical concept, at least the way I see it, the more your test environment(s) looks like your production environment(s), the better. It means that even hardware, location, operational system, etc, have to be considered.
It all comes down to how much "effort" the project is willing to invest on the quality of the product.
You are supposed to run automated integration tests based on your product and project contexts. There isn't a single and final answer to your question, because there are a lot of variables that have to be considered.
Does anyone do option #2?
Yes, I do use a embedded application server but I only used it for database integration but you can apply that for functional automated testing as well.
How are you supposed to start an application server from tests?
One option is to use embedded containers that you can manage with Maven profiles. I recommend you to follow this Arquillian Getting Started guide to understand how it works, and then you can apply the same concept for Selenium and Spring.
I usually go with option 2 -- I use the Maven Jetty Plugin to start an application server running the webapp (usually under a 'test' profile to swap out certain dependencies like the database) and then run Selenium against the locally hosted application. You can bind the Jetty plugin to pre-integration-tests, and stop it in post-integration-tests.
I typically also include the JaCoCo plugin to instrument the Jetty JVM so that I can check coverage from Selenium-style integration tests.
Related
I have a Java Spring Boot Application, and I build it with Maven. With
spring-boot-maven-plugin,
I can create fat, executable jar file.
Then I copy it to the remote server and run. But sometimes,
I change only one line or event one word in my code and I had to do whole build/copy step again. I'm sure that I'm doing it wrong, but I couldn't find another way that more efficient (Like capistrano in Rails).
At this point, I'm planning to clone source code to server, push from local, pull from remote, build and run approach. What is the correct (or elegant) way of doing this deployment?
For automatic build and deployment process (continuous integration), you can use Jenkins. Refer this documentation for more details: https://jenkins.io/doc/
I would say it depends where are you trying to do it.
The best and the most agile way to do it for a controlled environment is surely a CI-CD (Continuous Integration and Continuous Deployment) pipelines, which complies-builds-tests-deploys your code against every commit made to the source code BUT it may be too slow to use CI-CD for a development environment where you had like to have a shorter feedback cycle and faster feedback to see how the code is progressing.
However, if you are talking about development environment, I will hit another chord and ask you why to deploy to the external server AT ALL while developing. When you use Spring Boot, which helps you develop a self-contained application, you get the Tomcat Server embedded with it for free. That gives you the choice to run the code anywhere you develop and test to move forward.
A simple maven goal - mvn spring-boot:run can make the code run anywhere you had like.
There is another magical library available in Spring-Boot, known as Devtools, which is meant to support agile developers. The library once in the app classpath, performs hot-swapping of byte-code to auto reload of code into the running application (running locally with embedded Tomcat) as soon there is a saved change. This is one of the coolest gadget that a developer can have.
Use of Spring-Loaded (or JRebel for non spring-boot apps) libraries can also help a developer do hot-swapping of byte code to load changes in running application as soon saved.
I hope it helps.
I am a Java developer, not a QA engineer, so my question may seem trivial to some.
How do I run my integration tests post-deployment? In normal build and deployment process, all JUnit tests are executed prior to deployment. After deployment is done, testing (as I understand) should be done using other (black box) methods. But what if I want to periodically check my application using my nice suite of integration tests?
What would be a proper way to run IT tests against an existing deployment (including production)?
Many companies have two environments: production and UAT. The production environment is the live production site. UAT has the same build as production but can be used for testing, trying things out, and comparing if production has a problem.
Should you want to run JUnit tests on production (and like cjds i don't understand why you would), then UAT is the place to do it.
Is it possible to automate tests on a server using puppet ? I have done some research but cannot find any accurate resources. if its possible, can it be done without the puppet enterprise ?
I am trying to test how much load a software (java server) can handle under different configurations, is it possible to do this using puppet?
If someone can direct me to a good source that'll help a lot.
Thank You.
What kind of testing are you after for this
possible to automate tests on a server using puppet ?
As you know Puppet is about managing your (test) infrastructure, like getting the required this test environment to the desired state (fixtures). My guess is that you need to consider one of the most used CI servers - Jenkins, TeamCity or Bamboo. They all can support your testing process. As example I've used Jenkins and remote physical machine to run
API tests on it, and TeamCity and remote VM for my Selenium grid server.
UPDATE:
For your performance testing you can use some tool like JMeter, framework like Grinder or your own framework implementation with some client like google-http-java-client. And Puppet to tune this java server
under different configurations
per test execution.
We have recently started TDD and we are writing JUnit test-cases for each of the RESTful webservices that we develop. Is it a good idea to run the JUnit test-cases on the production environment when a new version is released?
Background:
Our web-app is enterprise web-app and has complex business logic. The plan is to use #After and #AfterClass to cleanup the test-data generated by running test-cases.
The web-app is available as both SaaS and on-premise editions and we are planning to validate upgrades for both edition if it's feasible and a good practice. I understand that we will be having this test-cases run on staging environment but to make sure that we have not broken anything during upgrade/deployment or environment has not created any diverse affect.
Now question is, "Is it good practice? if no what is suggested?"
Your unit tests should just test the code. They shouldnt be modifying with external sources like databases and/or web services then they become integration tests.
Generally I would suggest running unit tests before building/deploying your project to production, these can be run on a build server or QA / staging server. Only if they all pass do you deploy to production, then you know the build is stable in that sense.
If you have integration tests that do speak to other services and may modify data etc, I wouldnt run these on production. I would run them on your QA/Staging server against the code that is about to be released to production.
This is an interesting question; I would say no you don't want to run a full unit test suite, however you might want to invest in maintaining a separate deployment smoke test suite.
Reason - it's possible your test suites could affect a prod database, e.g. bug in an actual test fails to rollback or something.
Also, you are not wanting to test your whole codebase in prod, just verify it deployed OK (assuming you got satsifactory results when you did run your whole test suite).
We're migrating our application into a Java EE container, and looking for tools to use for unit testing (and integration testing) our migrated app.
Our requirements include:
Ad-hoc testing: the ability to run tests manually, on demand (to be used by developers while developing code)
Batch testing: the ability to run a large (and growing) set of tests regularly
In-Container: integration tests that use EJBs as they are deployed in the container
Unit testing: Testing of classes not necessarily inside an EJB context
Nice to have: Simple to set up, integrates with ant/IDE
No requirement to test Servlets/JSPs - only POJOs and EJBs
What are you using to achieve testing in Java EE environment? What technologies/setup have you deployed?
My research have uncovered Cactus and JUnitEE: have you had success setting them up?
We use normal JUnit for both unit tests and integration testing. We switch between the two using a VM argument, and have the tests annotated with markers for direct vs. server. We do have a custom TestSuite class though that finds and runs the tests based on this information, as it was easier and less error prone than manually maintaining which tests to run.
In our case we use Spring remoting to talk to servlets and EJB's (via the servlets), and testing both cases is simply a separate launch configuration within Eclipse.
We used JunitEE a few years ago, but eventually gave up on it in favor of just using JUnit throughout. This enabled us to have developers do all their testing without a server at all and run both unit and what I would call low level integration tests in their IDE. Then we let the build machine run the same integration tests against the same code now deployed in the actual server. This makes the development cycle much faster as we rarely need to run the server and deploy service code.
JUnit(EE) is what every major project($100mil+) I've supported has used. It's really a fantastic tool and knowing how to use it is invaluable when/if you decide to look for other job opportunities.
I supported a government financial system that used no unit testing but after a lot of pushing we finally implemented JUnit. The system I work on now is a large government agency modernization and we use JUnit for all of our unit testing. The two large firms supporting the modernization have essential made JUnit the standard across all of the sub projects. We've got ~200 developers using it without a hitch.
It's quick and easy to set up and once you understand it and you can leverage the features it will demonstrate how invaluable it is.