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.
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.
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.
I am pure developer and spent most of time in writing the java classes , but the case of junit test cases , I become little bit lazy is there any plugin that can be installed in eclipse that will generate my junit test cases automatically..!! Please advise
MoreUnit is an awesome plugin that generates test classes and allows easy navigation between test and class under test. It can also generate test method stubs and mock boilerplate, but I don't think these are as useful.
As for the test code itself, the only way around writing it is to get someone else to write it (i.e. executable specifications).
The JUnit plugin stubs out the methods for you, which is all you should need. It's up to you to know what and how to test. There is this tool from Parasoft, but I have never used it, so can't say how it is.
I'm currently re-using JUnit 4 tests from another project against my code. I obtain them directly from the other project's repository as part of my automated Ant build. This is great, as it ensures I keep my code green against the very latest version of the tests.
However, there is a subset of tests that I never expect to pass on my code. But if I start adding #Ignore annotations to those tests, I will have to maintain my own separate copy of the test implementation, which I really don't want to do.
Is there a way of excluding individual tests without modifying the Test source? Here's what I have looked at so far:
As far as I can see, the Ant JUnit task only allows you to exclude entire Test classes, not individual test methods - so that's no good for me, I need method granularity.
I considered putting together a TestSuite that uses reflection to dynamically find and add all of the original tests, then add code to explicitly remove the tests I don't want to run. But I ditched that idea when I noticed that the TestSuite API doesn't provide a method for removing tests.
I can create my own Test classes that extend the original Test classes, override the specific tests I don't want to run, and annotate them with #Ignore. I then run JUnit on my subclasses. The downside here is that if new Test classes are added to the original project, I won't pick them up automatically. I'll have to monitor for new Test classes as they are added to the original project. This is my best option so far, but doesn't feel ideal.
The only other option I can think of is to run the bad tests anyway and ignore the failures. However, these tests take a while to run (and fail!) so I'd prefer to not run them at all. Additionally, I can't see a way of telling the Ant task to ignore failures on specific test methods (again - I see how you can do it for individual Test classes, but not methods).
If you can't touch the original test at all you are going to have some serious limitations. Your overriding sounds like the best bet, but with a couple of changes:
Build the Ant tests specifically excluding the super classes, so that additional classes that you don't know about get run.
You can use the #Rule annotation (new to JUnit 4.7) to know what test is being run and abort it (by returning an empty Statement implementation) rather than overriding specific methods, giving you more flexibility in knowing whether or not to avoid the test. The only problem with this method is that you can't stop the #Before methods from running using this method, which may be slow. If that is a problem (and you really can't touch the tests) then #Ignore in the overridden method is the only thing I can think of.
If, however, you can touch those tests, some additional options open up:
You could run them with a custom runner by specifying the #RunWith tag on the class. This runner would just pass over execution to the standard runner (JUnit4.class) in that project, but in your project (via a system property or some other mechanism) would inspect the test name and not run a test. This has the advantage of being the least intrusive, but the most difficult to implement (runners are hairy beasts, one of the stated goals of #Rule was to eliminate most of the need to make them).
Another is to make an assumeThat statement on the test that would check some configuration setting that would be true if that test should run. That would actually involve injecting right into the test, which is most likely a deal breaker in anything remotely labeled a "separate project."
It doesn't help you now, but TestNG supports this sort of ability.
OK, this is a rather heavyweight solution, but don't throw things at me if it sounds ridiculous.
The core of Junit4 is the org.junit.runner.Runner class, and its various subclasses, most importantly org.junit.runners.Suite. These runners determine what the tests are for a given test class, using things like #Test and #Ignore.
It's quite easy to create custom implementations of a runner, and normally you would hook them up by using the #RunWith annotation on your test classes, but obviously that's not an option for you.
However, in theory you could write your own Ant task, perhaps based upon the standard Ant Junit task, which takes your custom test runner and uses it directly, passing each test class to it in turn. Your runner implementation could use an external config file which specifies which test methods to ignore.
It'd be quite a lot of work, and you'd have to spend time digging around in the prehistoric Ant Junit codebase to find out how it works. The investment in time may be worth it, however.
It's just a shame that the Junit Ant task doesn't provide a mechanism to specify the test Runner, that would be ideal.
A possibility I can think of to achieve what you want with the stated constraints is to use bytecode modification. You could keep a list of classes and methods to ignore in a separate file, and patch the bytecode of the test classes as you load them to remove this methods altogether.
If I am not mistaken, JUnit uses reflection to find the test methods to execute. A method rename operation would then allow you to remove these methods before JUnit finds them. Or the method can be modified to return immediately, without performing any operation.
A library like BCEL can be used to modify the classes when loaded.
If you want to run only a subset of the tests it sounds like that class has more than one responsibility and should be refactored down. Alternately the test class could be broken apart so that the original project had all the tests but on one or more classes(I'm guessing some of the tests are really integration tests and touch the database or network) and you could exclude the class(es) you didn't want.
If you can't do any of that, your option of overriding is probably best. Take the process of whenever you need to ignore some methods you extend that class and add it to your Ant exclude list. That way you can exclude what you can't pass and will still pull in all new tests (methods you didn't override and new test classes) without modifying your build.
If the unwanted tests are in specific classes/packages, you could use a fileset exclude in Ant to exclude them during import.
Two options
Work with the owner of the borrowed tests to extract your ones into a separate class you both can share.
Create your own test class which proxies the test class you want to use. For each method you want to include have a method in your class. You'll need to construct an instance of the test class you are calling and do before and after methods too if they're in the original.
Create a custom Junit runner based on blockjunitrunner and use it to filter out or in the tests you want.