I'm working on a project where we need to compile groovy classes at runtime and then instantiate objects from these classes and execute methods on it. The source for these classes exists as a string only in live environments.
These classes can contain pretty complex code, so there is a good chance of bugs hiding in there.
The problem with our approach is, that when we notice missbehavior in these classes, we can't use a comfortable method of debugging.
We can of course write and execute tests against these classes, but often times you just want to know what's going on step-by-step.
So my question is: Is there is a way to debug runtime generated groovy/Java classes?
The steps we currently take to track down bugs:
1) Write tests to reproduce the behavior
2) Read through the code. (obviously has a super bad success rate in complex classes)
3) Do instrumentation. We call a static "_break" method which we have written in a utils class (so no runtime generated stuff). In that _break method we can add a breakpoint. So this is almost as if we were debugging the runtime generated classes directly. The Problem with that approach is, that you have to recompile and add a new version of the groovy classes to the testsystem everytime you want to add/remove a _break call.
If you're wondering how we can even write tests for these classes, here is how:
For unit tests we copy the code from the strings into regular groovy classes. These are used for development and unit testing, because it gives us code completion and a fast way to at least execute the classes against simple tests.
We can debug the code on unit test level. The problem here is, that the data setup is too complex to reproduce certain combinations in unit tests.
For integration tests, we do the whole compilation, adding, executing process, just like it would happen in the live system.
We use Intellij 2017 as IDE and I currently have no idea if or how we could "connect" the bytecode to either the strings which is was generated from, or the copied groovy classes we use for unit testing.
Any other tool that would allow us to debug would be fine as well.
Related
Is it possible to run a non-main method without running the main method (and thus the whole class)?
It seems like this would be useful to test your code while writing an incomplete program.
It’s called unit testing and for Java JUnit would be the most common tool for the job. It will allow you to run single classes or methods. To further help you out, a mocking tool (for example Mockito) will allow you to substitute classes with mocked implementations so you can construct a class without having to construct all the dependencies for real.
Since you mentioned your IDE, IntelliJ (and all IDE’s worth mentioning) have extensive support for JUnit. Usually there is also support for code coverage so you can even see how much of your code is being tested by your tests.
Hi recently we have done the unit testing for the entire project using mockito framework. My project is on Java spring rest project. But the coverage is below 35%. Need to improve the unit testing coverage.
1. Want to remove the unneccesay package from the code coverage, like test packages and beans class
2. Do we need to write the unit test case for the controller class and generated class from the tools.
I will be very grateful, if you can help me.
Test classes and packages are not counted in test coverage, if they were, how do you test the code that tests the code etc..
When you run coverage it should only run over src/main/Java etc.
Controller classes should be tested, when you call a method, is the correct delegated class and method called?
Generated classes, if from xml using jaxb etc do not need to be explicitly tested if they are just plain old Java objects with getter, setters and fields. It's likely they will be tested via another class that uses these objects and calls their methods. These classes will be generated/compiled before your tests run so will be available- make sure you aren't committing generated classes to your code repository.
You may want to consider testing the behaviour of third party libraries you depend on. This way you can instantly see if any updates to libraries may cause issues, but this should be from a high level.
You need to not start ignoring classes, but instead run a code coverage tool and see what's uncovered, and get those unit tests up to par. Test your failure cases, too!
The test packages should NOT be part of the 35%, so removing them is not going to help. None of the coverage tools I know of consider test packages.
As for generated classes - most likely not, but again, run a code coverage tool and you'll quickly see what needs to be covered.
If you use IntelliJ then coverage tools are built in:
https://www.jetbrains.com/help/idea/2016.2/code-coverage.html
Eclipse uses plugins, one is:
http://www.eclemma.org/
There are more if you google.
I prefer Sonar:
http://www.sonarqube.org/
But whatever tool you use, that's the way to go.
I am trying to create an index of unused Java methods in the form of a json file.
There are a couple different ways in which the methods can be referenced. I have already checked for all the other ways and have a relatively small list of possibly unused java methods.
The final way in which a method can be used is in other java files. They would be called with a basic class.method(args,args2,etc...) syntax somewhere in the java source code.
My question is, is there an easy way to just check my list of possible unused methods to see if any of them are not used in the java code. It would be ideal if this could be done at runtime, but it would also work if I could create a file that I could then read in at runtime.
I have tried using pre-built software like UCDetector, but the source code is huge, and running UCDetector takes hours and often doesn't even finish. It also checks all methods to see if they are used which is a waste of time since I have narrowed it down to a small number of possible methods to check.
You should use your IDE (eclipse, intelliJ), or some static code analysis tool such as findbugs, pmd, checkstyle.
It seems like you are trying to reinvent the wheel.
One option might be to use "coverage analysis" tools to see what is not used (https://en.m.wikipedia.org/wiki/Java_Code_Coverage_Tools). If you have good branch coverage with your unit tests, simply running the tests with coverage will yield the result you're looking for. If you don't have good tests coverage, you might run the application itself with code instrumented for coverage calculation, but as with unit tests - the quality of the result will depend on the amount of code executed with your unit tetst or manual test.
Some examples of the coverage tools you might use are : JaCoCo (http://www.eclemma.org/jacoco/) and Cobertura (http://cobertura.github.io/cobertura).
Alternatively you might instrument your code yourself in order to log methods usage, as it might be more lightweight than calculating full line coverage. This is however indeed reinventing the wheel.
This SO question has similar solutions: How to find unused/dead code in java projects
So my issue is that I am working on a Java project in IntelliJ IDEA and in my working directory, I have 12-13 Java class files.
I am working on each Java class, and I would like to use JUnit to test the methods I implement in each class.
I have set up a testClass for one of these classes, however, when I try to run it, I guess Java tries to compile everything in the directory and because the other classes aren't implemented, it doesn't finish compiling.
My question is: What is the best way to do unittests on individual class methods without having to implement every class in my directory?( I come from a python background so is this question even relevant in Java?)
Thanks.
If your class does not call methods of those other classes in the methods that you're testing, then it shouldn't be an issue if the compiler fails to compile those other classes. Provided the class that you're testing compiles, you should be able to run anything in it.
However, if your class does call methods in some other class that doesn't exist yet, then you probably want to just to put "empty" versions of all the methods that you want to call into the required classes. This will enable you to compile the class that you wish to test.
If you want the methods that you're calling to have specific behaviour within your unit test, in order to test some condition that can arise when you call those methods, then you should look into using a "mocking framework". I can happily recommend either JMockit or Mockito (although I have to admit to being loosely affiliated with the Mockito development team).
First, welcome to the Java language! May you have as good of a time with Java as you have with Python. Most build systems (Ant, Maven, Gradle, etc) generally compile all source files within a project directory. In order for the compilation phase to complete successfully you need a program which follows the language semantics as well as any symbols referenced (classes, methods, packages, etc) to be resolvable.
While building software in Java your best bet is to leave the files within your project in a sane state. This will allow you to test features as you complete them. I've been in positions while placing code under test where I had to temporarily comment out code which broke until I could fix other pains first.
As #David Wallace pointed out Mockito and JMockit are excellent tools for mock based testing with inter class dependencies.
Is there a program out there that can allow me to find all ignored junits?
By this I mean, I have seen unit tests that use the #Ignore and tests with method name like ignore_testFoo() or xtestBar() or xxtestBar1(), which all get ignored and they are very hard to find sometimes.
I could grep for those cases, but I was wondering if there was an application that would find any of those situations automatically.
I tried using cobertura to obtain coverage on junits, to see which methods were being executed and which were not being executed, and picking apart the bad unit tests that was.
I was just wondering if there was a program or another method to obtain this information without hacking something up.
A static analysis tool would serve you well here. Checkstyle is a decent choice amongst them, it has a long list of modules, and worst case you can easily write your own module to validate any coding convention you need.
You would locate or create a module for it then execute to find any non-conforming code.
Edit
PMD looks to be an excellent choice to handle this task. It actually comes with a set of JUnit rules already built in and its very easy to combine rules or create new ones.
It should be easy to detect ignored tests using junit3 by a grep on your java test files. Find all lines matching test and parenthesis but with a method name that doesn't start by test.
For junit4, you could
* implement your own test runner by extending the default one, print out ignored tests
* build a small app that loads test classes, get all declared methods through introspect, print out those markedas ignored.
There may be a tool to do that, maybe even some runners already do, but actually it could take a few hours to have those tools from scratch if you really need them.