I'm doing Java development in eclipse and using JUnit. My application uses an old version of a library because of platform restrictions. Is there any way I can run my unit tests with a new version of the library? How do you configure a different build path for unit testing?
To clarify for everyone below:
Here is the problem. Our platform requires a really old version of the java Servlet library. But we want to use ServletUnit (a library for testing servlets in a unit testing framework). This library will only work with newer versions for the java servlet lib. I don't care that we test with a different version of the servlet library, it outweighs the negative.
You can do this by having your unit tests in a different project, so the projects will have different build paths.
The better question is WHY you want to do this. It's a bad idea to run your tests against something other than the production code. Why not either update the library in the application, or use the old library for the tests?
In response to your edit:
If you don't care about testing with the same libraries you use in production, then you don't care about code quality or correctness. There's no point in answering this because no answer will be a good fix to your problem. Your time would be better spent upgrading your platform to use the newest version of servlets.
Related
I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.
I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.
What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens' and 'read the documentation here: http://spring.io/' would be very helpful)
The system:
Java 6 - jax-b/-p/-ws/, Apache Commons,
Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi
Hibernate 3.5
Tomcat 6
0 unit tests or automated testing of any kind.
Maven dependency management and build automation.
Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.
Hundreds of views, scores of controllers.
Steps I've taken so far:
Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)
I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.
My questions:
What steps/procedures are considered 'best practice' in these for a job like this?
Does anything jump out at you as a 'gotcha' for a job like this?
Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:
Requirements, requirements, requirements
Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.
If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.
It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.
Spring projects have evolved a lot. Budget for learning time.
This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:
Java 8 features
JavaConfig (as opposed to xml configuration)
Acegi is now Spring Security
Spring projects typically use Spring Boot
Switch from Maven to Gradle for building projects
Full CI using Jenkins (or other CI tools)
Unit and integration testing have moved on to using annotations (and mock frameworks)
Well, it is not easy to answer you question since there are many things to be taken into account.
First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guide that's coming directly from the 'source'.
I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries.
Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts.
Take also a look to the dependency updates section.
Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).
I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.
Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).
It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.
You should also become familiar with Spring 4.x new features and try to exploit them especially those regarding testing improvements.
A little resume of new features is the following:
Removed Deprecated Packages and Methods
Java 8 Support
Java EE 6 and 7 become the baseline
Groovy Bean Definition DSL
Core Container Improvements
General Web Improvements
WebSocket, SockJS, and STOMP Messaging
Testing Improvements with extreme use of annotations
Take also a look to Spring MVC Test Tutorial by Petri Kainulainen that can give you a lot of informations about testing.
You have to have answer to the following before you proceed.
Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?
OR
You really want to get the most out of Spring 4.x ?
Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.
So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.
You may redesign the whole app in Spring 4 as if it is a new application.
Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.
From Migrating from Spring 3 to Spring 4, you would probably get some help from the Spring project's
Spring Integration 3.0 to 4.0 Migration Guide on Github.
Hope it helped!
Usually, when developing algorithms for android applications in eclipse, I used pure Java projects that would have a dependency set to the android project and could then run JUnit tests in the pure Java classes. This had great advantages since I could run my tests on my algorithms and logic classes really quickly without any deploying.
Could anyone tell me if it is possible (and how) to do something similar with android studio??
Thanks!
How about the gradle android test plugin?
("A Gradle plugin which enables good 'ol fashioned unit tests for Android builds." sounds like what you want)
Or maybe something like robotium / roboelectric.
I have an existing java application which is developed in Netbeans this is my first major development project so i didn't think about the use of log4j & junit in first place(A good lesson learnt). since now i am at the end of the project i miss these two . is there is any tool or jar which can create automated testing & logging with minimum effort ? I guess Adding log4j is easy but what about junit ?
There is nothing to say that you cannot use Junit after you have created a project. It means that you are not making use of test driven development, but there is no reason why that is an issue once you have already created your project.
I would recommend the netbeans tutorial on exactly how to do that:
https://netbeans.org/kb/docs/java/junit-intro.html
I've recently begun working with a large, legacy enterprise Java application. It's primarily built on Websphere Commerce 6. It contains a mix of EJB 1.x and 2.x along with quite a bit of code that hooks directly into the Commerce API.
I've introduced the first unit tests while attempting to break dependancies and carefully refactor small portions of the code. We've been exploring the idea of using an integration testing framework to make the process of creating tests less fragile and time consuming.
Arquillian has been suggested as a very good option for integration testing. However, it looks geared towards more "modern" applications; most of the examples make use of Java EE 5+ and Maven. We're using J2EE and Ant. We're also currently tied to Java 1.4, and while it may be possible for us to move to Java 5, we won't be upgrading to EJB 3.x any time soon. We're also likely to stick with Ant.
With these constraints in mind, is it possible to use Arquillian? Or do better alternatives exist for integration testing legacy enterprise Java applications?
Arquillian has been suggested as a very good option for integration testing. However, it looks geared towards more "modern" applications; most of the examples make use of Java EE 5+ and Maven. We're using J2EE and Ant. We're also currently tied to Java 1.4, and while it may be possible for us to move to Java 5, we won't be upgrading to EJB 3.x any time soon. We're also likely to stick with Ant.
With these constraints in mind, is it possible to use Arquillian?
Note: I'm an Arquillian contributor. I've tried to be unbiased in my answer.
This would really depend on how your tests are executed. If you are attempting to use Arquillian's support for in-container tests, then you're unlikely to find a solution. WebSphere Commerce 6 uses WebSphere 6.0 as the underlying container, which is not supported by Arquillian at the moment. If you can hypothetically use a version of WebSphere Commerce that uses WAS 7.0 or 8.0 as the foundation, then most of my answer can be ignored, since these containers are supported.
You can attempt to run tests from the client using the #RunAsClient annotation, instead of the container, and this is more likely to succeed. Note that, you'll need to perform the deployment in some manner without a #Deployment annotated method, because of the afore-mentioned absence of support for WAS 6 in Arquillian.
If you intend to use Ant instead of Maven, then the only requirement is that all dependencies be present in the classpath. Unfortunately, there is no uber JAR or distribution for Arquillian, so for now, you'll need to know all the dependencies upfront.
Note - Building in WebSphere 6.0 support for Arquillian may not be a trivial activity, as compared to other more recent containers:
Firstly, there have to be means for deploying the archive. I'm not sure if the mechanism used in WebSphere 7 and 8 container support can be ported over.
Supporting in-container tests in Arquillian for WAS 6.0 may require supporting the Servlet 2.4 protocol for running tests. Currently, Arquillian supports Servlet Spec 2.5 and 3.0 for packaging it's ServletTestRunner. This is of course, necessary if the JMX protocol and the accompanying JMXTestRunner cannot be used.
Or do better alternatives exist for integration testing legacy enterprise Java applications?
I would normally advise folks to use a mix of Cargo and JUnit for functional testing legacy apps, but even Cargo does not appear to support WebSphere 6.0.
You might find JUnitEE to be a better fit for your needs if you are willing to package the JUnitEE TestRunner in your archive; note that JUnitEE's last release was in 2004, and the mailing list is a bit inactive, so YMMV.
I want to ask for your prefered way to test Java EE code?
I found only three project, that are trying to help to code unit tests in Java EE environment:
http://jakarta.apache.org/cactus/ : Last Published: 2009-01-18
http://www.junitee.org/ : Last Release: 2004-12-11
http://ejb3unit.sourceforge.net/ : Last Release: 2008-05-17
So I wonder,
is there any framework helping to write (j) unit test for Java EE code?
do you use embedded Java EE servers like jboss or glassfish v3?
do you mockup and inject by yourself?
Thanks a lot...
If by Unit Testing you mean... unit testing (testing a unit in isolation), then you actually don't need any particular framework since EJB3.0 are nothing more than annotated POJOs and thus can be relatively easily tested without any special fixture.
Now, if you mean something else - like Integration Testing or Functional Testing - then, yes, tools can help and simplify things (but you should really start to use the right terminology :) I'll assume that this is what you have in mind.
First, JUnitEE seems dead and obsolete and I'm not even sure it has anything for EJB3.x. Second, I'm not impressed by the Java EE 5 support of Cactus and having to deploy Cactus tests is painful (I think that Cactus was nice for J2EE 1.4 but is a bit outdated now). So this leaves us with Ejb3Unit which is in my opinion the best option, especially if you want to run out of container tests i.e. without really deploying the application (much faster).
If you want to run in container tests, then you could indeed use an embedded container and my current preference goes to GlassFish v3, even for Java EE 5 (I may be wrong but I'm pretty disappointed by the starting time of the latest JBoss releases so it isn't getting much of my attention). See the post GlassFish Embedded Reloaded, an appserver in your pocket for sample code (that you could use from your tests) or Using maven plugin for v3 embedded glassfish (if you are using maven).
Another option would be to package and deploy your application with Cargo and then run some tests against the deployed application (with Selenium or a BDD tool for example). This could be useful if you want to run end-to-end tests with a container that doesn't provide any embedded API.
So, to answer your last question, I would indeed use available tools, maybe a combination of them, for tests that are not unit tests and wouldn't mock/inject stuff myself, except if they don't cover some needs that I can't think of right now.
As you are interested in unit testing, I recommend JUnit. You can unit test the methods in the core classes. If you have difficulty in writing unit test cases using JUnit, then probably the design is not modular and it is highly coupled. First focus on your core functionality and test it using JUnit.
I've been facing the same problem of running integration tests based on JUnit in a Java EE 6 container (Glassfish v3, to be precise), and after a lot of browsing and searching, I could not find a solution that really suited me needs, so I wrote my own, now published as jeeunit on Google Code.
I wouldn't call it a test framework, it is really just a handful of classes providing the glue between JUnit and Embedded Glassfish.
The general idea is similar to Cactus, your tests run in the container and get triggered by a servlet from outside.
jeeunit supports JUnit 4, Glassfish v3, CDI and generates the standard XML JUnit reports just like Ant or Maven Surefire (in fact, I reused some code from Ant for generating the reports).
I had a requirement to test a CDI application and wrote a custom JUnit runner that runs everything outside of the web container.
http://jglue.org/cdi-unit/
It is suitable for Java SE and also supports dummy Request, Session and Conversation scopes for testing web apps.
It's small and fast, which is great when you have lots of unit tests.