Leider kann Ihr Browser nicht alle Designelemente dieser Seite korrekt darstellen. Damit Sie trotzdem die kompletten Inhalte sehen können, bieten wir Ihnen diese abgerüstete Version an. Um das korrekte Design der Seite zu sehen, probieren Sie bitte einen anderen Browser.

 

FAQ

If you have any question about JUnitDoclet, please check, if it's already on this list. Only if not, please send an email to junitdoclet@objectfab.de. Thank you.

drucken top

 

The generated code is not compilable. Is it a bug?

In most situations it is not a bug. JUnitdoclet does generate non compilable code whenever you should decide, what to do there. For example:
  • A Singleton has a private constructor only. The generated method createInstance won't compile, but now you are aware of the problem and you can handle it the right way.
  • When testing accessor methods of a floating point attribute (types float or double) the assertEquals method does require a third parameter for delta. Even if 0.0 would be ok in most cases, JUnitDoclet can't be 100% sure. But you can, so you decide. (Other tools would have decided this on your behalf, and you would have serious problems finding the cause of the problem in the very few occations when 0.0 is not ok. Our approach is different: There is no need to outsmart JUnitDoclet.)
  • A constructor may require a parameter. Which value should JUnitDoclet use? You know that, so you change the code. JUnitDoclet will remember your change when regenerating.
  • The default tests for accessor methods with interfaces or abstract classes try to create an instance of that interface or abstract class. You know which situations you want to test, please modify it the way you need it there. For the future, we have some more advanced ideas on this matter.
Please read "Is JUnitDoclet just another wizard?" as well.
drucken top

 

Is JUnitDoclet just another wizard?

No, it does some repetitive tasks for you, nothing more, nothing less. JUnitDoclet just can't solve all the problems, and it won't even try to. It was designed to behave reasonably and predictably. In contrast to many "wizards" and "assistants" you stay in control. You don't need to outsmart JUnitDoclet. If it can't handle something, compiling the generated test will fail. This way you learn about the problem and solve it the right way. JUnitDoclet keeps the solution when re-generating. Fair enough?
JUnitDoclet is standing at your side, not in your way.Please don't get the (deadly wrong) impression, that the number of tests says anything about the quality of testing. If most of the tests are empty, you didn't get the point!
It remains your job to write the tests, but JUnitDoclet is helping you as good as it can.
If you want to change generated code, please do it. That's why we inserted the markers, just write your modifications between them. ;-)

drucken top

 

Can I use JUnitDoclet in my project?

Yes, as long as you follow the rules of GNU LGPL.

drucken top

 

My handwritten test methods get overwritten. How do I avoid this?

Put all your handwritten code between markers. Always! If you want to write a test method by yourself, write it between the marker at the class level. The marker is already there. (The instance under test is defined within this marker as well.)

// JUnitDoclet begin class
  org.junitdoclet.demo.SampleClass sampleclass = null;
  
  // and now a handwritten test method
  public void testHandwritten() {
    // ...
  } 
// JUnitDoclet end class
drucken top

 

My handwritten TestCases are not executed in the TestSuite.

If you create a TestCase by writing everything yourself (which is good for more functional tests) just insert the call for that TestCase in the TestSuite you want. That's what the markers in the suite method are for.

public static TestSuite suite() {
  TestSuite suite;
  
  suite = new TestSuite("org.junitdoclet.demo");
  suite.addTestSuite(org.junitdoclet.demo.SampleClassTest.class);
  
  // JUnitDoclet begin method suite
  suite.addTestSuite(org.junitdoclet.demo.MyOwnHandwrittenTest.class);  
  // JUnitDoclet end method suite
  
  return suite;
}
drucken top

 

Why is fail(); not default for all test methods?

You are not bound to the default. If you would prefer to have every new test fail, you can change that in your project specific properties. But before you do that, please read our reasons for the default setting.

JUnitDoclet is intended not only for XP in new projects, but for stabilizing existing applications as well. (The projects don't have to be XP either.) If you run JUnitDoclet for the first time on a project with serveral hundred classes, you would end up with thousands of fail(); statements. It would take you days, to get back to actual development. We believe, this is not a good way to get people to write more tests.

A new project does not have that problem. Why not use fail(); as the default there?
Especially new projects are very dynamic. Classes appear and disappear, methods move between classes, they show up and vanish a short time later. In short: You do Refactoring, which is a very good thing. JUnitDoclet is supporting Refactoring. If a marker from the old file has no counterpart in the new file, it is moved to testVault (a special test method each Test has). But there is one exception: If the marker is empty, it will be gone without any further notice! If all method markers would contain fail(); you would end up with many warnings. They will get you bored and you slow down testing. We don't want that.

Programming has to be fun to deliver quality software. Tools have to serve the developer (not vice versa). Developers are smart and know what they are doing. If you do Test Driven Development you will write tests because you do TDD, not because of a tool that generates fail(); statements.
In short: JUnitDoclet is standing at your side, not in your way.

Note: Without fail(); as the default, you may get thousands of empty test methods. If they stay empty, this isn't better than no tests!
The fun of writing the actual test functionality remains your responsibility!

To find empty test methods, please use a script for now. (Damian O'Neill wrote one he likes to share.) Future versions of JUnitDoclet may offer other help here.

drucken top

 

When I'm renaming a method, the existing test will be in the right place after regenerating. How could JUnitDoclet know?

You are using a tool that can rename in comments, when performing that refactoring. (IntelliJ IDEA is the tool we are using for development of JUnitDoclet). The markers are comments and your tool finds them. :-)

drucken top

 

I'd like to do some diagnostic checks on Mockobjects and test helpers. How I generate that tests with JUnitDoclet?

Be carefull, explicitly testing of tests could lead to an infinite recursion. We like to think of the test being tested by the application while the tests show the absence of possible errors in the application. After all, that is why in Test Driven Development (TDD) you want to see a test failing first before you make the application pass the test.
If you really know what you are doing, pass the "-testintest" option when invoking javadoc. Only then JUnitDoclet will generate TestCases for helper classes in test packages and test trees, but no TestCases for TestCases or TestSuites.

drucken top

 

How does it integrate with my current tool set?

If you are using ANT, just create a target for JUnitDoclet. It will be executed just like javadoc, but with a few more arguments. The critical part is the definition of the package and the main TestSuite. Please use the build.xml from the demo as an example. If you want a more responsive integration, you find examples for integrating JUnitDoclet in your favorite development environment in the "doc/ide" directory of the distribution (1.0.1 or above provide help with IDEA and Eclipse).

In summer of 2005 Fabrice Bellingard suggested a plugin for Eclipse (called: e-junitdoclet) which he offered to write. It is available as Beta 1, so please go ahead and check it out.

Feel free to contribute your own macro or description for your favorite environment. Just send an email to junitdoclet@objectfab.de.

drucken top

 

Can I use JUnitDoclet for J2EE applications?

Yes, but we didn't do that so far. (When developing J2EE applications, you often generate your classes from a model. Why not generate the test skeletons from that model as well?)

How do you test EJBs anyway? There are several ways to do it, none is as widely spread as the JUnit framework itself, so we don't support them. Here is a list of things to do:

  • Write your own templates. (They are specific to your way of testing. We can't provide a general solution.)
  • Write your own TestingStrategy. (To generate tests for the Bean implementation (*Bean.java) only just implement the isTestableClass method differently than in DefaultTestingStrategy).
  • You may even write your own NamingStrategy to avoid names like "HelloBeanTest".
drucken top

 

How do I define a constant name for all TestSuites (like AllTests)?

Just uncomment the property testsuite.class.name and assign the name you want. Make sure, JUnitDoclet finds the property file you modified.

drucken top

 

Can I use JUnitDoclet with Test Driven Development only?

It works just fine with other approaches as well. In fact, JUnitDoclet is very useful, if you need to cover existing code with tests later on. And it always supports refactoring. Your test code won't get lost, even if you rename or move methods.

drucken top

 

How can I use the -source 1.4 in ANT with JUnitDoclet?

The documentation of ANT 1.5 says, that the source option of the ANT task is not used with custom Doclets. (If you set -source 1.4 you make javadoc aware of the assert statement.) JUnitDoclet does not require this information, but javadoc itself does (not just the Standard Doclet as the ANT folks guessed). Please include -source 1.4 as part of additionalparam.

drucken top

 

How can I exclude some packages?

The parsing is done by javadoc, not by the Doclet. That's why javadoc has to exclude a class from processing. Please see documentation of the javadoc tool or ANT.

drucken top

 

Can I use an ANT-fileset to select files for JUnitDoclet?

Yes. Since version 1.0.2 some bug that made it more difficult is removed. But be aware, if you don't pass in packages you don't get TestSuites. ANT-filesets are sets of files, so you will end up with TestCases only. This is not as bad as it may seem, since you can use the <batchtest> of the JUnit integration with ANT to execute all your tests.

drucken top

 

I can't use JUnitDoclet as an external tool from IDEA. What's wrong?

We hear this message from people who have a classpath with 2500 chars and 50 different JAR files in it. It's no surprise, IDEA can't pass this classpath as a parameter to the script file executing JUnitDoclet. Treating the symptoms would be to modify the script to use a default classpath, but curing the disease is to use a much shorter classpath.

drucken top

 

I get a warning about an invalid file. What's wrong with it?

In most of the cases one of the markers was deleted or modified by accident. With IntelliJ IDEA this may happen, if you optimize imports in your TestCase. IDEA removes comments in the import section as well.

drucken top

 

How can I contribute to JUnitDoclet?

We would like to make JUnitDoclet more known to all the JUnit fans out there. The more people know it, the more will use it. The more users it has, the better we can make it. If you used JUnitDoclet and just want to vote for it, please go to the project description at freshmeat.

drucken top

 

What will be new in JUnitDoclet 2.0?

First of all, we want to keep everything as close as possible to release 1.0.2.

  • The template mechanism will change from one file for all templates to one file per template. We want to get rid of the line numbers and indentation problems this way. A converter will be provided.
  • The core of JUnitDoclet will be freed from all dependencies to the JavaDoc API. It is the first step in preparation of plugins for modern IDEs. Of course, there still will be a doclet frontend to the core.
  • The new release will be able to generate abstract TestCases for interfaces and abstract classes. Those tests will be applied to all instanciable classes implementing the interfaces / deriving from these abstract classes.
  • How about reusing test cases? Liskov Substitution Principle says, a class B derived from class A should behave as class A, too. Applying the tests from ATest on B would verify that. Because these additional test cases can be generated without manual interference, one will get even more out of exisiting test cases.
  • Some users of JUnitDoclet complained, that one test method per application method sometimes is not enough. We will provide a way to handle those rare situations in a convenient way.
drucken top

 

What date the new version will be released?

Honestly, we don't know. We are working on it and hope to release a first preview soon. Fortunately our consulting services are in high demand, which does have it's downside when it comes to free projects as JUnitDoclet. ;-)

drucken top