I was wondering whether anyone is using Jython to write JUnit tests? The reason for this is that I try to find a neat way to test my SOAP based web services without the need to generate any code. The reason for sticking with JUnit is that I would love to eventually integrate the tests into my Ant based CI system.
I already had a look at the article http://www.devx.com/java/Article/26602/1954 which describes exactly what I need. Unfortunately, I wasn't able to get it working.
Any thoughts and experiences on this would be of great help.
Thanks,
Alex
I'd rather go the other way round: write tests using python unittest to test java code from python. You could then have doctests as well to test Java code, which is neat.
Then you could attempt integration in ant by creating an ant task that e.g. runs 'nose' to find and execute the tests.
Or you can decide to use Hudson for continuous integration (which is going a long step beyond simple Ant) and never look back... ;)
A nice article with this and more (including a mention of the jython plugin for Hudson):
http://www.jython.org/jythonbook/en/1.0/TestingIntegration.html
I have written jython code to test Java projects in the past. Saves me the headache of typecasting and accelerating the death of my keyboard with excessive keystrokes.
import sys
sys.path.append('path/to/library.jar')
from com.example.library import Foo
import unittest
class TestFoo(unittest.TestCase):
def testFoo():
bar = (2, 3, 4)
foo = Foo(bar)
self.assertIn(2, foo)
Related
I was not able to find any test cases for java source code. I thought having a look at test cases for some of the advanced java classes would be a great way to learn about the class and also would be a great insight on writing test cases. Are there any test cases that test Java source code ?
You can check out the OpenJDK source code here, and browse around. They're using a Mercurial repo, so you can click on jdk, then browse on the left bar, then test to start digging through the test code.
It's worth noting that this isn't necessarily the most modern way of testing java code - usually, you'd want to use a library like JUnit to manage your tests. OpenJDK is simply using a makefile, to ensure that there are no dependencies when building Java.
I am currently working on a Java library - that is, a bunch of classes that are exclusively intended to be used in other projects. Naturally, it has no main() function.
Now, I want to test my progress. And by "test" I don't mean some professional standardized system; I mean I have a very simple function that I want to run to gather information, which will be modified as the project becomes more complete.
I was hoping I could drop an executable class into the Test Packages folder, and just click Run. Unfortunately, NetBeans complains that there are no main classes found.
So, how do I test a library project, without adding an executable class to my distributable source?
You should absolutely look into unit testing frameworks, such as JUnit. IDEs typically have support for running tests easily, and it looks like Netbeans does too. (I don't use Netbeans myself, but I'd have been shocked if it didn't support JUnit.) It's a lot simpler to do this than to have main methods everywhere. After all, a main method will only test one route through your code - with unit tests, you can have lots of tests, each testing one small piece of your code.
Even if you don't want to go into unit testing in a fully-fledged way (which I'd strongly urge you to, by the way), unit tests can be a very straightforward way of just running some code and experimenting with it. I sometimes use it when developing against a 3rd party library for the first time - leaving unit tests to show and document my understanding of the library's behaviour. (Obviously the better the library and its documentation, the less need there is for this, but it's still useful...)
I have used both JUnit and CPPUnit in Netbeans extensively and find that it is fairly easy to get test coverage for libraries with those tools. IntelliJ IDEA does a decent job with JUnit as well so that is an option if you don't like the Netbeans interface. The xUnit frameworks have gotten me out of a jam many times since they are very good at isolating errors quickly. As Jon said they also help to capture the requirements/behavior of your system so that is an added bonus.
I am trying to find the execution flow in a large java code base which is not written by me. I have searched for tools which make that possible (JSonde, JTrace, Java Call Tracert, JavacallTracer), but the problem is that they all should be used with a single java/jar/class file.
The code I am trying to understand is built with Ant and has hundreds of jars. So, it runs using a shell script. I do not know how to use those tools with this code.
I really appreciate your help.
I know, that this is an old question, but now I found a solution and I put it here if somebody else searches the same thing: http://findtheflow.io/#gettingstarted.
I think what you should consider is a code coverage tool. This will report what parts of your code are executed and which are not. There are several such tools to consider. Jacoco is an emerging favourite and is associated with the Emma Eclipse plugin.
The thing to remember about code coverage is that it needs to be driven by something. Normally this is accomplished by running your code's tests (unit or integration).
Finally, once you've comfortable with how to enable code coverage you could also consider uploading and archiving it's results in Sonar.
I'm using eclipse in a Java environment. I have to introduce testing to an already underway project. How to start? Unit tests on the classes, and what else? What are the best tools for the job (considering I'm using eclipse)? TestNG, JUnit, JTiger?
How do I make others adapt themselves to use the tests?
Thanks in advance!
Eclipse has a great support of JUnit. This looks like a great starting point. I would add a new source directory test and create a package structure mirroring your src folder. Then you can add your unit tests one by one. Good luck!
Unless your team already is used to writing tests, testing all old components is not really feasible (sometimes not even then), as writing testable software requires a specific mentality.
I think, the best time to start writing tests is when you can define some new component that is critical enough to warrant the extra effort, but somehow new, so the already existing code base would not be tested as much.
This way you could find a testing approach, identify the benefits and learning the mentality without putting too much effort in something that might not work for your team.
About tooling: I sadly cannot really compare the different tools, as I only have experience with JUnit.
JUnit is easy to start with, as the corresponding tooling is already included in Eclipse (wizards to create templates, running and evaluation options...), and there are plenty of documentation and examples available on the net.
A lot of good questions.
If your project does not tests at all and already underway you should introduce the tests incrementally. When you have to develop a new feature write test for this feature, classes that you are going to change and features that could be broken. The same is when you are fixing bugs. First write test that reproduces the bug, then fix it.
I used JUnit and TestNG. Both are almost the same. TestNG has groups, i.e. you can mark test to be belong to group like development, build, integration, etc. This is mostly relevant if you have a lot of tests and it takes significant time to run them all.
Do you already have automatic build? If not start from this. If you prefer to use maven it is relatively simple. When your build is ready write a couple of unit tests (just to have something to fail...)
Then install Hudson/Jenkins and define your project there. People will see how cool is it that once you commit your new code the build runs almost immediately and you see all failed tests. Probably try to show the strength of TDD to your boss and try to explain him that he should force all team members to write tests.
If you have enough energy introduce Sonar to your company. People will see how awful the code that they are writing and how poor the test coverage is. The they will see how quickly the test coverage is growing up and will probably invest more into unit testing.
Shortly, good luck. You are on the right way.
JUnit and TestNG are both fine. TestNG has more capabilities and can be helpful with integration tests, JUnit is more focused on unit tests.
You may want to get acquainted with some kind of mocking library like Mockito. Code coverage tools like Cobertura and continuous integration tools like Jenkins are great too.
Using a DI framework like Spring or Guice is helpful for writing more easily-testable code. Whether you use a DI framework or not, the more loosely-coupled your code the easier it is to test. Since your project is already under way it is probably too late for this part, which will make your task harder.
It can be very hard to get co-workers to cooperate with testing. You may want to introduce it selectively on pieces where it can make the most difference. Writing tests for already-finished functionality is usually painful and a waste of time. Tests should be small, have few dependencies, be understandable, and should run quickly. The more painful it is to write tests, run the tests, and fix broken tests, the more resistance you will get.
is it possible to hook up an agent or something to the jvm before starting up an application (or an appserver) and have a report showing how much of the code base in the classpath is actually executed for a given use case ?
I want to figure out how much code is left out unexecuted for my simple servlet application running in an appserver which doesn't use many j2ee technologies like JCA, JMS, CMP, etc.
Best regards,
Bulent Erdemir
What you're looking for is a code coverage tool.
For Java, I've had a great deal of success with EMMA. You should be aware that any code coverage tool is likely to affect performance significantly - typically it's used for unit testing, to check that your unit tests hit appropriate parts of your code. You could use it for a test run of a web app as well though - I'd just recommend against using it for the production deployment.
I prefer cobertura over EMMA. At least when I used EMMA it generated a number of false negatives (lines that were actually executed but it said they were not). EMMA may have fixed this.