I wonder is there any id or specified label to distinguish a selected class whether it is one of the standard class declarations or test class in run-time?
EDIT: I collect the entire classes from the project. I separate abstract classes, interfaces, subclasses by looking the collection, whereas I also want to know how many classes have test behavior. In other words, how many classes are actually test classes. One more thing: I don't know these classes in advance, these are not mine!
Let me share with you how I like to organize my tests in eclipse :-) maybe you may find useful.
First, I create two projects, one for the app and another for the test.
The test project, of course, has a dependency on the app project
Now, let's suppose you want to add some test case, you just point to the right src dir.
So you want to create your test code without mixing app code and test code (for example, utils), just leave what's specific to the right project.
The only name convention I use is the eclipse junit default, appending the word "Test" in the end of the test class.
No need for ant scripts to deploy only the app code.
Even JUNIT dependency is restricted to the test project.
I hope it helps.
Related
My current project contains an interface and an implementation of a RandomTextGenerator type (such as might be used in an adventure game to generate original character or place names). I am using Maven to compile and package the project and JUnit 5 for unit testing. I'd like to structure this project properly in order to open-source it (if only just to learn the proper setup).
My JUnit tests do a lot, but they can't qualitatively test the big question: do the randomly-generated names come out sounding good?
How should I test this? Options I'm considering:
Add a new class with a static void main() that generates and prints a bunch of these names to System.out.
Add a JUnit test that does the above and then ends with assertTrue(true).
Build a new project outside of this package, which imports the package and does the above.
I'd like to know what's the generally-accepted best practice, given my intent to open-source this project. Would consumers of my package want to see these tests, or not, and where?
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 have a complex class (300+ lines), which I'm trying to test from different "points of view". I've already created three different unit tests. Every test is a complex class itself (100+ lines). The question is -- what is the best place to store them, in project directory tree? This is how I'm doing it now (Maven is used):
pom.xml
/src
/main
/java
/com
/Foo
ComplexClass.java
/test
/java
/com
/Foo
/ComplexClass
FirstPointOfViewTest.java
SecondPointOfViewTest.java
ThirdPointOfViewTest.java
Of course, the names are just placeholders, used in order to explain the problem/question. What do you think about this approach?
Your class is so complex that you need three different test classes to test all the aspect of the class? Probably you have mixed too many concerns in a single class. I would suggest refactoring the class using proven design patterns to separate classes with orthogonal concerns that can then be tested individually.
One thing you might want to consider: if you keep your test code package structure the same as your main code package structure---even using different physical directories as you are currently doing---your test classes will be in the same logical package as your main classes. This means they gain access to default/protected members in the tested classes, which is often helpful. You'd have to get rid of the ComplexClass package in the test code to make that happen.
Another thing to consider: (I'll assuming you're testing with JUnit) Test classes are classes, so you can organize and structure them using inheritance. If you have 3 different points of view, maybe extract a base class which contains common functionality, this will make your tests easier to maintain in the long run, especially as more "points of view" are discovered.
Separating the source and test code as you are already doing is a great idea, it gives you more options for building and maintains a logical grouping which makes maintenance more straightforward.
I'd keep what you currently have. The main advantage of this maven structure is that rather than mixing source and test code together and trying to identify which classes to exclude from your build you just ignore the test directory entirely. The point of using the same package is to expose protected methods/variables to your test classes but not to a public API.
One thing I might suggest is something I picked up at a talk by John Smart on Test Driven Development which is to name your test classes in groups of functionality they are testing, so you just have FirstPointOfView.java which is testing the behaviour of your first point of view of the com.foo package. This approach should make it more obvious when you can split a test class into individual classes, if they are actually testing different sets of behaviour.
Edit: if ComplexClass is a directory you should drop that, so that your tests are in the same package, I think I may have missread your example tree
I often use the refactor -> rename functionality in eclipse and I also have the habit of naming the associated unit test TestedClassNameTest. But when I rename my tested class I must not forget to rename my unitTest. It would be extremely useful to rename my unit test automatically when the tested class is renamed.
I guess it wouldn't be that difficult to create a plugin that does the job but maybe that isn't even necessary?
I've found a plugin that does the trick http://moreunit.sourceforge.net/
After several googling and eclipse searches, it seems such feature is not yet available.
Today there is no notion of "class being unit tested" in Eclipse. What I mean here, is that you can create a Unit test classes testing anything you want: a full package, a single class, a single method, a full plugin ....
To get more accurate, there is "NO relation in Eclipse's model" between your tested class and the associated unit test.
I totally agree with you that it would be nice to such a feature in Eclipse. To go further it would be really cool to be able to generate Unit tests skeletons and thus have these tests classes linked to the tested ones.
May be you can laucnh the discussion on Eclipse Buzilla, maybe in the PDE category.
Manu
eclipse would not figure this out to change: It only changes the references of the method used in other classes or in the same class.
If you really want to make this functionality work, you could extend eclipse's refactoring API as I did for my project and give it this new functionality.
If you like to have any references on this just ask me ;-)
I am learning the concepts of Test-Driven Development through reading the Craftsman articles (click Craftsman under By Topic) recommended in an answer to my previous question, "Sample project for learning JUnit and proper software engineering". I love it so far!
But now I want to sit down and try it myself. I have a question that I hope will need only a simple answer.
How do you organize your JUnit test classes and your actual code? I'm talking mainly about the package structure, but any other concepts of note would be helpful too.
Do you put test classes in org.myname.project.test.* and normal code in org.myname.project.*? Do you put the test classes right alongside the normal classes? Do you prefer to prefix the class names with Test rather than suffix them?
I know this seems like the kind of thing I shouldn't worry about so soon, but I am a very organization-centric person. I'm almost the kind of person that spends more time figuring out methods to keep track of what to get done, rather than actually getting things done.
And I have a project that is currently neatly divided up into packages, but the project became a mess. Instead of trying to refactor everything and write tests, I want to start fresh, tests first and all. But first I need to know where my tests go.
edit: I totally forgot about Maven, but it seems a majority of you are using it! In the past I had a specific use case where Maven completely broke down on me but Ant gave me the flexibility I needed, so I ended up attached to Ant, but I'm thinking maybe I was just taking the wrong approach. I think I'll give Maven another try because it sounds like it will go well with test-driven development.
I prefer putting the test classes into the same package as the project classes they test, but in a different physical directory, like:
myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java
In a Maven project it would look like this:
myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java
The main point in this is that my test classes can access (and test!) package-scope classes and members.
As the above example shows, my test classes have the name of the tested class plus Test as a suffix. This helps finding them quickly - it's not very funny to try searching among a couple of hundred test classes, each of whose name starts with Test...
Update inspired by #Ricket's comment: this way test classes (typically) show up right after their tested buddy in a project-wise alphabetic listing of class names. (Funny that I am benefiting from this day by day, without having consciously realized how...)
Update2: A lot of developers (including myself) like Maven, but there seems to be at least as many who don't. IMHO it is very useful for "mainstream" Java projects (I would put about 90% of projects into this category... but the other 10% is still a sizeable minority). It is easy to use if one can accept the Maven conventions; however if not, it makes life a miserable struggle. Maven seems to be difficult to comprehend for many people socialized on Ant, as it apparently requires a very different way of thinking. (Myself, having never used Ant, can't compare the two.) One thing is for sure: it makes unit (and integration) testing a natural, first-class step in the process, which helps developers adopt this essential practice.
I put my test classes in the same package as what they are testing but in a different source folder or project. Organizing my test code in this fashion allows me to easily compile and package it separately so that production jar files do not contain test code. It also allows the test code to access package private fields and methods.
I use Maven. The structure that Maven promotes is:-
src/main/java/org/myname/project/MyClass.java
src/test/java/org/myname/project/TestMyClass.java
i.e. a test class with Test prepended to the name of the class under test is in a parallel directory structure to the main test.
One advantage of having the test classes in the same package (not necessarily directory though) is you can leverage package-scope methods to inspect or inject mock test objects.