I am curious to understand how Java tests its APIs. Let's say,I am interested in the class ConcurrentHashMap, will there be any unit tests for this class? If so, is it available for public?
When you say "Java" you probably mean the Java Development Kit (JDK), which comes as OracleJDK and OpenJDK (OracleJDK is essentially OpenJDK with a few extras). OpenJDK is open-source; and the source code for all of its projects can be found here:
http://hg.openjdk.java.net/
In particular, here is a browsable version of the jdk7 project directory.
I am curious to understand how Java tests its APIs. Let's say,I am interested in the class ConcurrentHashMap, will there be any unit tests for this class? If so, is it available for public?
Yes, for a list of all jdk7 tests look in jdk7/jdk/test.
If you are interested in ConcurrentHashMap tests, look in jdk7/jdk/test/java/util/concurrent/ConcurrentHashMap:
NOTE: The JDK tests may look a bit awkward because it does not use JUnit, it uses JTreg.
Any class packaged inside jdk like ConcurrentHashMap is tested and you don't need to worry almost all the cases. If you implementing a well defined interfaces then there are test cases available which can run against your API and check whether it's complacency. In addition if you define a new API which you will expose, you have to write your test cases using JUnit or TestNg. Here the purpose of your test cases should be checking whether your API giving expected results. If you cover all the combination of using your API then you can identify when there is a regression.
Offtopic : Integration testing suppose to test the whole project when all the components are integrated.
[Update] If you really need to test ConcurrentHashMap you can use a sample project which uses ConcurrentHashMap, please keep in mind that you better choose multi-thread project.
You probably won't be able to get the source (and thus the testing code) for Oracle's Java. However, since OpenJDK theoretically follows the same specifications for behavior as Oracle Java (at least for all the parts of it that I'm familiar with), you could perhaps use their unit tests to test your library. The source for OpenJDK's jdk8 can be browsed here (see the test directory for tests), and you can find other versions of java at their main page.
However, as Erranda points out, you should really ask yourself if you want to test the existing libraries. They are probably more thoroughly tested than anything you'll end up writing already, and unless you want to recompile Java from source after finding an issue (which could lead to compatibility problems), what good would finding a bug in the libraries do?
Related
TL;DR
I have a Java project that I build and test with maven. What it the simplest way to run my junit tests on an Android sdk?
More details
After a commit, a user open a bug report to explain that I broke the compatibility with android since I introduced a dependency on javax.xml.bind and this package doesn't exist on Android.
Now I managed to implement my feature without using this package, and I'd like to be sure I don't break this compatibility anymore. Consequently I'd like to run my existing junit4 tests on the Android Sdk. The issue is that I'm an Android noob, and I'm starting to drown under documentations:
would using local unit tests fit my needs?
If yes, may I use them with maven or shall I switch to gradle first? (ie: the documentation explains how to do it using Gradle. Is it a prerequisite, or is it possible to do it with my existing build system?)
Or must I go through the burden of using instrumented unit tests? (Are those even usable given that there's no notion of UI at all in my project?)
Yes. Android Plug-in for Gradle keeps track, that you're not using APIs your are not allow to use due to API level minSdkVersion limitations of the lib. (I'm pretty sure, it also archivable with maven-android-plugin)
It's possible and requires Surefire Plugin. I haven't try it personally, unfortunately, so I can just say that from what I briefly read - it looks ancient and not particularly easy to set up. So if I were you, I'd go for Gradle. But if costs of it is too high - well. It's doable with maven too.
Unless you want to test activities and some complicated end-to-end UI(fragments, intents, etc.) scenarios - you're good to use JUnit tests. And even if you do need something Android's Activity/Fragment-related, you can use Robolectric lib for it (it's a unit test framework, allows to avoid instrumented tests in many cases)
Context
Basically, I have a library that is used in several applications running on java 6, java 7 and now java 8.
The library also has a dependency on a creepy (yet very useful) third party library (which I won't name) - a library that doesn't care a lot about forward-compatibility. The aforementioned applications also make heavy use of this third party library but are not always able to update to the latest version. I'm used to it, so I have a lot of "if" in my code dealing with silly things.
Problem
Today I stumbled upon an annoying problem: some method in the third party library has a different behavior when running in java 7 and earlier than when running in java 8 and later.
My unit tests were designed to cover this part of my code and would have spotted the bug if they were run with the correct java / library combination.
Question 1
How can I integrate nicely in the maven build lifecycle and run my tests sequentially with java 6, java 7 and java 8? (which implies failing if any test fails with any jvm)
Question 2
Same as above but adding another sequential run with each "supported" version of the third party library ?
(which means, to be clear, that, if I "support" version 6.11, 6.12, 6.13 and 6.14 of this lib with all 3 java versions, I will run 4*3=12 times my unit tests)
i have similar problem. i created a library that should be tested against different versions (all available in maven central) of other library and (but that's less important) jvm.
my conclusions: doing this only in maven will be veeeery cumbersome and hard, if not impossible. you will also have to encode environment/system dependencies into your build tool
as suggested, most integration servers support matrix tests. you can use it also to manually provide every single version (if you know them upfront) of library you need to test against. the library part should be doable much easier in gradle (but still no out-of-the-box support).
regarding number of tests: yes will have to run x * y times. if your code is big think about isolating the part that uses other library and run only this small part x times for each jvm - it will be a bit faster. also you can run those tests in parallel
ps: i'm thinking about writing a gradle plugin or at least a proof-of-concept build. but i don't think it will be soon. but i'm open for other contributors :)
Is there a quick way (e.g. tool) to detect, from the source (or maybe even from compiled classes), which parts of an application call Java API methods that are only implemented in a specific Java version? (e.g. which parts of my app are Java6-specific)
I don't necessarily want to hop through all ClassMismatchErrors and avoid the trial-and-error-method. Let's say I only want to document which parts of an application won't work if they were writte for, e.g., Java6 and I want to run it in a version 5 JDK.
Is there something like this? Google did not help this time, nor did I find any solution here (a rare case indeed:)
The Animal Sniffer might be helpful for this, especially its Maven plugin.
If I understand you correctly, what you're describing doesn't sound like a very good idea to me.
It sounds like you want to build some library on JDK 6 (specifying -target 1.5), but let it be run on JDK 5 and just have certain classes or methods here and there just not work (because they needed a Java6-only API). I wouldn't do this. A method which should work might still trigger a class to be loaded which itself contains some reference to a class that's new in Java 6, and an Error will be thrown.
It's much better if you just choose which version is your minimum supported version and live with that.
Can someone please explain the following
How was the first JDK release unit Tested? Since Junit came after Java how did they do it?
Are the current releases using Junit to test the JDK API?
Regards
The JDK is tested , at least now, using jtreg . I am not aware of any usage of JUnit to test the JDK.
Unit testing is a concept and a practice. It is not a package or specific implementation thereof (although it was admittedly popularised by JUnit).
I don't know what's the Sun, Oracle :-), standard is for testing. I'm sure it's pretty thorough though. Bear in mind there is more than on JDK publisher.
I imagine that the very first JDKs (pre Java 1.0) were tested using a harness implemented using other technologies; e.g. C, shell scripting, and so forth.
Certainly Java unit testing was done in Java well before JUnit came along. I remember using a framework developed in-house at DSTC in the late 1990s, and the GNU Classpath project used a framework called Mauve. Java test frameworks are not rocket science.
I'm going to give a talk about using Java and Scala together and I want to investigate some projects (large and small) which contains Java and Scala code.
If you know links to correspondent projects post them here.
This page on the Scala wiki is a good starting point...
The various scala testing frameworks come to mind. They all have some integration with JUnit or TestNG
Gimd is one example of small project: http://code.google.com/p/gimd/
Although development stalled for a while because I'm busy with other duties it already contains some examples of Scala<->Java integration. Notably:
unit tests are written using junit
Gimd is using JGit (library in Java) as underlying layer
While working on Gimd I found that using Java from Scala is mostly easy and seamless the contrary is not always true. It's not really a fault of Scala as it's simple manifestation that Java is a less expressive language.
Unfortunately I don't know any open source project but I have worked on very large projects over the last few years that have java and scala interacting and my experience has been mostly very positive. If I had one piece of advice it would be to use scala-javautils. It's a life saver and is far better than the scala jcl code. Before we started using it trying to get some interactions involving collections was heart-breaking. However I'm led to believe 2.8 will solve this.
In general I find the interactions between scala and java very close to using one language.