When we are using Test driven devleopment, I always wonder how you easily reach or create the test class in Eclipse.
We have a maven setup with two source folders src/main/java and src/test/java
When I am opening a class in src/main/java looking for a bug, I want my test class side-by-side. But I have to search the tree for it. Of course you can use a search box like "Open Type", but it is still annoying and takes a lot of time. And when i go to the test my package explorer to the left shows the test package, so I can't see the other classes in the package and cannot easily open them.
Do I miss something to support my TDD workflow?
What is the best setup to have the test near by?
The title of your question speaks about a bad practice: keeping production and test code together. This is a bad practice because there's the risk of deploying also tests in the final package(s).
But reading your request (if you are using JUnit) it looks like you want an Eclipse plugin such as MoreUnit which creates a shortcut and makes easier working with JUnit files by decorating source classes etc.
This plugin has also been cited in other SO responses such as:
Eclipse function/plugin that finds corresponding junit class?
Furthermore sometimes a production class is used in more than one test class you may also search for all occurrences of that source class and limit your result scope to test packages. If you don't use JUnit but instead you use another framework such as TestNG you will have to search for a different plugin because MoreUnit is JUnit specific.
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?
I'm a CS master student. Throughout my studies I coded many course projects in Java. Soon I will graduate. When I explore some github projects I often find people organize their projects as /main and /test. I have never organized it in such a way, i.e. I always have my source code files without any test directories. I think that folder often contains what I think is called 'test cases' or so.
Since I will find a job soon, then I would like to learn about production-quality code.
My questions:
Why people often have that folder? What does it contain?
Can you provide me with a link to a good tutorial about the practice of testing in java? i.e how to do it? In a nutshell I wanna understand the idea of that /tests/ folder.
I often find people organize their projects as /main and /test
This is a matter of taste. Not 100% sure but at least maven projects have such organization.
From Maven: Introduction to the Standard Directory Layout, this would be the project layout:
src
main
java <-- your Java source code
resources
filters
config
scripts
webapp
test
java <-- your unit tests for Java
resources
filters
it
assembly
site
Why people often have that folder? What does it contain?
Usually, people write test cases to cover the code and check if the code works as expected. This is known as Code Coverage. Code coverage also serves as regression tests in case somebody makes changes in the code for enhancements like code refactoring.
The test cases you will find them usually are for Unit Testing. Depending on the type of the project, you could also find Integration Tests.
There is also Test Driven Development, or TDD, which is a practice whose basis is writing the test cases before writing the real code.
Can you provide me with a link to a good tutorial about the practice of testing in java?
This is off topic for the site. There are plenty tutorials on the net about this.
I don't have a separate folder for mine but usually people keep their Unit Tests in that folder. A unit test generally sets up "fake" data to test a given class so that a developer can easily debug any issues.
The reason people provide a /test folder is to contain unit test for their project.
There are really many ways of testing Java but JUnit is a very commonly used method of testing.
It is a good practice to write tests for your code. Begin with writing Unit Tests. I found this tutorial very useful. Writing test ensures that your code behaves as expected , corner cases are tested and adding new code in the future does not break existing functionality.
There are also mocking frameworks like JMock and Mockito that make writing stubs and drivers for your methods easy.
What is even more interesting is people prefer writing tests before they write the actual implementation. This approach is called Test Driven Development or Extreme Programming. Writing tests first ensure one already has a prep code or pseudo code for the methods in mind.
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.
I've been searching high and low for an Eclipse feature that lets you right-click on a main source class and find the corresponding JUnit class(es), without me having to navigate through the test classes of my project. I am using Mylyn which helps reduce the clutter but it would be much easier if there was a feature that performs a find automagically.
I am following the Maven standard directory layout (/src/main/java, /src/test/java, etc.). And all of my test classes are named *Test. I'd imagine this can be feasibly implemented and probably already exists.
Is there a function or plugin in Eclipse that finds the corresponding JUnit test classes for a given main class?
The moreUnit plugin probably works for you.
Capabilities (from its site):
Decorate classes which have a testcase.
Mark methods in the editor which are under test.
Jump to a testcase/testmethod in the editor via the menu or a shortcut.
Rename classes/methods and moreUnit will rename the corresponding testcode too.
Move classes and moreUnit will move the corresponding tests.
Generate a testmethod stub for the method under cursor-position in the editor via the menu or a shortcut.
This plugin claims to be able to do this, as well as other stuff.
An useful feature of this plugin is
the ability to jump between similar
class, e.g FooDAO to FooService,
FooService to FooAction, etc. To use
this feature, one needs to configure
this first. To configure, please go to
Windows -> Preferences ->Fast Code
Preferences -> Mapping Btween Similar
Classes. This is very similar to the
configuration for create similar
classes.
As a partial answer to your question, there is no requirement that tests have a one to one correspondence with main classes, or any standard naming convention (even with maven). What you would want is a plugin that (for example based on a regex) matches source classNames to dest ClassNames, and then loads that. Such a plugin would allow you to do what you want (and also for other uses not related to junit), but I'm not aware of one.
Infinitest plugin runs your JUnits for those classes that you're changing, as you're changing them. There is no need to right-click on the updated class to find the relevant JUnit class, and then to run it - it will get run automatically. Test errors (if any) will show up the same way as Eclipse shows syntax errors.