I've got two versions of a project with a JUnit test. Looking at the diff of the files there's no obvious reason to this, but the test passes on one project but not on the other.
For a while now I've wondered if there was a program that would record a trace through the whole program when it runs and save it to a file. This would be really handy for this exact example where I want a trace through both tests and then I want to diff them together.
Can anyone point me in the direction of a program that might be able to do this, or a way that I could diff the two program's flows?
Cheers
I'd use Aspects for this. Check out AspectJ for instance, it is very easy to design a rule (point cut) that says "For all methods invoked in my Java code, log method name".
If I understand your question correctly looks like this might partially achieve what you are after.
http://www.lambdacs.com/debugger/debugger.html
The Eclipse TPTP project has a trace engine that you might find useful.
Related
is there a way to print each line of source when the program executes without having to insert System.out.println after each line?
Use a debugger. Debuggers provide a number of useful tools to step through your program. Check your IDE, it probably has one.
First a question: Why would you need that? You might use a debugger if it's just for debugging.
If it is for logging purposes, logging each line would be overkill.
Second a suggestion: you might use AOP to log each method call (assignments etc. could not be intercepted), but that might require a lot of work (incorporate AOP into your build process etc.) and might not be worth the hassle.
Eclipse Test & Performance Tools Platform Project has a way to show you a sequence diagram of the program execution:
http://www.eclipse.org/tptp/home/documents/tutorials/profilingtool/profilingexample_32.html
For printing as text, AOP is nice but complicated, debug statements are easiest but most invasive.
I'm pretty sure Eclipse lets you step through the program line by line, the link is unfortunately down for maintenance but maybe check back on it later: http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.user/tasks/task-stepping.htm
I am working on a java project and I have to extend (add more functionality) it. But I don't know how should I learn the existing one before incorporating them.
Is there any specific path I should follow?
Can I run it in a way so that I can see, statement by statement, the execution of the program?
I am a kind of stuck in understanding it, thanks.
Here is another approach that is hacky, but I've found useful in the past when unable to attach a debugger. If there is a piece of code that you are looking at, but are having a hard time figuring out who is calling it you can throw a new runtime exception, catch it and print the stack trace.
try {
throw new RuntimeException("who is calling me");
} catch (RuntimeException e) {
e.printStackTrace();
}
You can always fire it up in a debugger/your IDE of choice and step through it all you want, though it's probably best to find someone who is more familiar with the source to provide you an overview, or to look for documentation on where to start.
Pick one piece of functionality for which you understand the requirements. Find the entry point for that feature and follow the code for that one feature. It should give you a good understanding of how the architecture works.
Integrating with code that is already written can be very difficult. In my experience, some of the best clues I've gotten about already-written code come from the method signatures (the mapping of the function's input to its output). The method's signature can give you a lot of hints about a program, namely where and especially how that particular method fits in the context of the larger program. Usually, a method signature coupled with a descriptive method name can give you enough information to be dangerous, especially in a typed language like Java.
Although I wouldn't suggest running the code line by line and looking at changes (because this usually amounts to tons of work) but for really ugly but important code sometimes it is necessary (I've definitley done it before using DDD for C programs). In this case, a quick google search reveals http://www.debugtools.com/ , a graphical java debugger, which may do the trick; there also seems to be version of DDD that works with Java.
This is a recurrent question on Stack Overflow. There is already very good answers all around:
https://stackoverflow.com/questions/3147059/taking-over-a-project
Cleaning up a large, legacy Java project
https://stackoverflow.com/questions/690158/how-do-you-learn-other-peoples-code
Also, this book might help: Working Effectively with Legacy Code
"Patience and fortitude conquer all things." - Ralph Waldo Emerson
I would recommend you to start with the debug as well so you can go through the program step by step.
Documentation:
If you have documentation, it’ll be helpful. But it can be a pitfall, as much documentation is out date, they can be misleading you.
Bugfix:
You could start with bugfix or new feature implantation. Start work with small scope, it’ll be easy work. During the bugfix, you could understand the code more and more.
Baseline the code, I generally would use git
Do a build of the application
Run it.
If baseline fails build or process is too complicated, create a branch and fix it
Create a branch and modify a string or something that would show some visible change if you modify the code.
If Javadocs are not created via ant or build files, create a new branch to do this.
If there is no JUnit test cases (or if there are but they don't work), create a branch and fix it.
Create a new branch to do the merge.
The following is if you're using Eclipse or similar product
If you're the only developer, create a new branch and set up project settings for code formatting and cleanup. Then execute the code formatting and cleanup. This would allow you to have a more stable baseline for future work. If not, try to coordinate with others.
Install FindBugs, Checkclipse, PMD to do some simple checks on the code base. Looking at WTFs sometimes will give you a better idea on how things are working (or not)
Install Eclemma and see how much of the code is actually tested.
I have written JUnit tests for my class, and would like it to tell me if there is any part of my code that is not unit tested. Is there a way to do this?
Yes, coverage tools like cobertura or emma.
They create reports that show every line in the source code and whether it was executed or not (and aggregated statistics as well).
Of course, they can only show you if the code was run. There is no way to tell if the unit test contained assertions to confirm that the result was correct.
You need some code coverage tools. See here (http://java-source.net/open-source/code-coverage) for some
If you look at the first one I think it does what you need
Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage. Features of Cobertura:
Can be executed from ant or from the
command line.
If you use Eclipse, you can also try EclEmma, which shows you which lines of source were covered by your test. This is sometimes more useful than running a coverage tool like Cobertura because you can run a single test from inside Eclipse and then get immediate feedback on what was covered.
Your headline and your actual question differ. The tools mentioned in the other answers can tell you, which part of the code were not tested (=not executed at all). Making "make sure that all parts of code is unit tested" is a different thing. The coverage tools can tell you whether all lines/instructions have been executed, but they don't guarantee that everything is tested functionally (all constellations of data, all execution paths, etc.). This requires some brain power.
In my opinion, test coverage often gives a wrong feeling of safety. E.g. testing trivial getters increases coverage a lot but is rather useless.
If you are using IntelliJ then there is a button titled
"Run With Coverage"
Is there a way to strip the JUnit #Test code from my Java class.
At the moment I embedded the test code in the same file as the source code to be tested
(Yes I know it's bad, but it is an incentive for me to keep maintaining my test code)
I'd like to strip the test methods from the code, build the binary and deploy.
Thanks
No, I don't know how you can do that, but I could tell you why you might not want to use this approach in the first place.
You might be able to strip out the tests, but what about all the imports that reference test libraries?
What about any private methods that the test might be calling? They won't be marked with #Test.
Why go through all this trouble in the first place? Every IDE has tools for automatically generating a test class and shortcuts for switching between them.
what if the test annotation was accidentally applied to one of your class methods?
What if one of your class methods accidentally calls a test method?
These are just some of the reasons I can think of... why no just avoid the problem in the first place?
There are no specific tools to do this task that I'm aware of.
You'll probably need to "take your licks" and make the changes the hard way with your favorite text editor / IDE. (And maybe this exercise will teach you to pay more heed to good practice / good style ... )
There are some tools that might help you do this (things that aim to encrypt your bytecode also tend to remove unused things).
However I would NOT advise doing that. It is good that you found a way to encourage yourself to keep the code tested (great infact!). However, as you have found out, the way you chose isn't all that good. There are many reasons to keep the test code separate from the code itself.
What I would do is (one class at a time):
1) bite the bullet and make a parallel set of classes for testing
2) move anything that has an #Test before it to the new classes
3) move over anything else that keeps the tests from compiling/running.
Then make use of a code coverage tool (I like Cobertura but there are others) to give you a visual of how much of your code is tested. Add to that the idea of writing the tests before you run the code and you should do well.
Basically this is a very formulated way of working. If you follow the regiment of coding and code coverage and then fix the places where the coverage is poor you should find it just as easy as if the test code is in the class. It is all habit - and good habits are better than bad :-)
Suppose that I have a Java program within an IDE (Eclipse in this case).
Suppose now that I execute the program and at some point terminate it or it ends naturally.
Is there a convenient way to determine which lines executed at least once and which ones did not (e.g., exception handling or conditions that weren't reached?)
A manual way to collect this information would be to constantly step with the debugging and maintain a set of lines where we have passed at least once. However, is there some tool or profiler that already does that?
Edit: Just for clarification: I need to be able to access this information programmatically and not necessarily from a JUnit test.
eclemma would be a good start: a code coverage tool would allow a coverage session to record the information you are looking for.
(source: eclemma.org)
What you're asking about is called "coverage". There are several tools that measure that, some of which integrate into Eclipse. I've used jcoverage and it works (I believe it has a free trial period, after which you'd have to buy it). I've not used it, but you might also try Coverlipse.
If I understand the question correctly you want more than the standard stacktrace data but you don't want to manually instrument your code with, say, log4j debug statements.
The only thing I can think of is to add some sort of bytecode tracing. Refer to Instrumenting Java bytecode. The article references Cobertura which I haven't used but sounds like what you need...