junitdoclet-users — Community support list for JUnitDoclet

[Junitdoclet-users] Problems with keyword assert

[Pirol_74 <pir...@ya...>]

Hi,

I try to generate some test-classes with the junitdoclet-plugin from maven
and have some problems. My sourcecode contains many assert keywords and if i
start the juntidcolet task i get this warning & error message:

[javadoc] Generating Javadoc
[javadoc] Javadoc execution
[javadoc] Loading source files for package de.jcrypt...
[javadoc] Loading source files for package de.jcrypt.container...
... warning: as of release 1.4, assert is a keyword, and may not be used as
an identifier
...

Is there a way to tell the compiler he should use 1.4 ?

Regards Pirol

[Junitdoclet-users] Two marker areas for each test method.

[<Rav...@bl...>]

Hi,

The default template provided with the junitdoclet release generates the
test methods with no source. Now, I want some source to be generated when
the javadoc is run.  So, I copied the properties file made the changes.

But now, we need two marker areas for each method. like.

public void testMethod1()
{
   int.. ;
    ...........
  .............
  .............
................

//junitdoclet end method name
...............
.................
..............
.................
//junitdoclet begin method name

//junitdoclet end method name
}


Has anyone of you had a similar requirement. Any links/ideas ?

thanx in advance.

Ravi.

[Junitdoclet-users] first-day experiences with JUnitDoclet

[Mike K. <mki...@al...>]

I'm now using JUnitDoclet, and I thought I'd share how my first day with it 
went.

I've summarized my setup issues in a previous message, but once it was 
installed, things went well!  I was able to generate, and regenerate, test 
cases (strictly StrutsTestCases combined with DBUnit this first day so I 
can't yet comment on the default template or default test cases).


The templating should really be improved.  The old "line-edit" method of 
numbered lines in a property file is very painful in this "day and age" of 
full-screen editors.  Fortunately, my years of experience on a vax mainframe 
with a dumb terminal gave me the necessary background to modify the 
template.

In some ways, it's probably handy to have all of the templating in one file, 
but I'd prefer to see it broken out into separate files and using a real 
templating engine (such as Velocity Template Engine 
http://jakarta.apache.org/velocity/ ) so we can have a lot more control of 
automated test case generation.


I'd also like to see the ability to have JUnitDoclet choose a template based 
on the Class superclass or the method signature, though.   Currently, in 
order to support a separate Struts Action test case template, I have to 
group all of my Struts Actions in the same package so I can specify which 
template based on the package name.  This goes against the idea than the 
test infrastructure shouldn't force changes to the application code layout.

Ie,

  <target name="junitdoclet.noactions" description="Generate non-action test 
cases" depends="compile">

    <javadoc

      packagenames    = "com.gvea.*"

      excludepackagenames = "com.gvea.struts.ebpp.actions.*"

      additionalparam = "-buildall">

    </javadoc>

  </target>



  <target name="junitdoclet.actions" description="Generate action test 
cases" depends="compile">

    <javadoc

      packagenames    = "com.gvea.struts.ebpp.actions.*"

      defaultexcludes = "yes"

      additionalparam = "-buildall -properties 
E:\Programming\Ebpp-struts\WEB-
INF\src\support\JUnitDoclet\templates\action.junitdoclet.properties">

    </javadoc>

  </target>



All in all, JUnitDoclet works well once setup.   I created 30 or so Struts 
action tests, discovered a few bugs in my code, and feel a lot better about 
the practicality of unit testing in general!

I do have one question about testVault (which runs during a test).  Is there 
a reason why it's named in such a way as to cause the code moved into 
testValue to execute during tests rather than being named "vault" or 
something else not tested?  

I'm gone for the weekend, but I'll be back Monday or Tuesday.   I'd be 
willing to help change the templating mechanisms if there's an interest.

-Mike

[Junitdoclet-users] Updates for the Eclipse and ant Setup documentation.

[Mike K. <mki...@al...>]

ste...@ob... wrote:
> Actually, we are working on a new version of JUnitDoclet
> which is going to be a _real_ plugin to eclipse (and to other 
> IDEs). We've seen many complaints from people that 
> had problems to get it started as an external tool (both in 
> IDEA and in Eclipse), so the plugin is a logical step.
> The importance of Eclipse has been shifting since the 
> release of JUnitDoclet. I -personally- may prefer IDEA, but 
> many people don't want to spend money if they can get a 
> similar tool for free. Eclipse-plugin is a MUST HAVE now.

Having tried to use junitdoclet in Eclipse, I think some of the problems =
can be improved by documentation changes.  But not all of them.

I'm using Eclipse 2.1.1 under Windows 2000.

I started off by trying to install it as an external tool  Eventually I =
gave up because I couldn't provide an alternate -properties file, and even =
making it work without alternate templates required hacking up the =
provided bat files.   Too much of a maintenance nightmare for very little =
gain.  Some of this could be reduced by rewriting the bat files to take =
arguments in arbitrary order.

However, I'm including a revised Eclipse IDE readme file for Eclipse 2.1.1 =
that will make it a little easier for those who can use it "out of the =
box."

[readme-Eclipse-2.1.1.txt]

Using it as an ant target worked a little better.  There will still =
problems with the example script under Eclipse 2.1.1.

Here's a revised Eclipse ant target to add to the documentation.

This target assumes you have a "compile" target and a "compile.classpath" =
property (seems likely).
This target assumes that you've put the JUnitDoclet.jar and =
packagelister.jar files in ./src/support/JUnitDoclet/
It's assumed that your source code is in ./src, and that your test cases =
will be built in ./test-src.

If you want to specify an alternate template file, add the following to =
additionalparam.   You cannot specify a relative path.

   -properties ABSOLUTE_PATH_TO_YOUR_junitdoclet.properties_FILE


  <target name=3D"junitdoclet" description=3D"Generate test cases" =
depends=3D"compile">
=09<path id=3D"junitdoclet.classpath">
=09=09<path refid=3D"compile.classpath"/>
        <pathelement path =3D"./src/support/JUnitDoclet/JUnitDoclet.jar"/>
        <pathelement path =
=3D"./src/support/JUnitDoclet/packagelister.jar"/>
=09</path>
    <javadoc
      sourcepath      =3D "./src"
      destdir=09=09  =3D "./test-src"
      packagenames    =3D "*"
      defaultexcludes =3D "yes"
      doclet          =3D "com.objectfab.tools.junitdoclet.JUnitDoclet"
      docletpathref   =3D "junitdoclet.classpath"
      additionalparam =3D "-buildall">
      <classpath refid=3D"compile.classpath"/>
    </javadoc>
  </target>

Re: [Junitdoclet-users] exception handling patch (bugfix)

[Nicola F. <nic...@va...>]

hi steffen

On Mon, 2003-04-07 at 00:09, ste...@ob... wrote:
> Well, who shows attitude now? 

At least I can make fun of me. I am certainly no code-god.

> > Thank you for this hard-to-find link! Was the reason to stick to this
> > license driven by the thought that someone would want to _include_
> > JUnitDoclet into some proprietary products? Or was it merely to allow
> > people to use (the free) JUnitDoclet to generate tests for their
> > (unfree) proprietary program?
> 
> Maybe a bit of both and some other reasons?

I don't know how many lawyers you put on this issue, but it seems to me
that GPL allows use of GPL'ed programs for developing
commercial/propretiary software (although IANAL).

> Properties may not be the coolest thing, but they 
> are installed where Java is installed. When they 
> go XML, JUnitDoclet will. 

ok, dependance of XML parsers is a reason. after nobody uses jdk 1.3
anyomore, there should be no more problems with that, since after jdk
1.4 there is JAXP and a default XML parser AFAIK.

ok, steffen, it was nice talking to you this weekend, but now I gotta go
back and use my brand-new and enhanced JUnitDoclet to write some
(almost) real software... :)

If anynone is still in my (bugridden? :) patch for JUnitDoclet, they can
visit: http://variant.ch/phpwiki/JUnitDocletPatches and get it there.

regards
nicola

Re: [Junitdoclet-users] exception handling patch (bugfix)

[<ste...@ob...>]

Nicola,

> And yes, I am fully capable of reading English books. thank you. :) 
This was not what I ment. ;-) Maybe you want to read the 
book anyway.

> And
> besides, I also fully agree that wizards are evil (at least most of
> them). Isn't JUnitDoclet a wizard? Hm.
See FAQ.
 
> > > That maybe have been the way it worked until now. 
> > 
> > Your statement does not sound like freedom to me.
> 
> Might be new for you: Freedom != Holidays

Freedom is the right to do whatever one likes as long as 
it does not interfere with the freedom of other people.

I like the sound of that.

> > Begging? Ever heard of feature requests?
> 
> Surely, but I have the feeling that even tough you honor a request, it's
> still the team leader that decides which suggestions are finally
> implemented (which is ok, besides). 

So why din't you even try to communicate with the team leader? 
Well, forget it.

> But for me writing what I need _is_ an option, so I use it when I have
> the freedom (and time :). Otherwise, I gladfully write some feature
> requests... :)

That's what the source code is for. Modify and use it.
If you like it, make it a feature request. So it may be in 
the next release and you don't have to worry about 
maintaining it.

> > It's not my ego, that was hurt. If only one other user applied 
> > your patch, he/she meight think different about our tool now. 
> > That is, what I don't like.
> 
> Do you know the Compaq FAQ entry explaining "where the Any-key" is? Some
> people never get it. Some people just shouldn't program (maybe me
> included - but who else would then get the work done? :).

Well, who shows attitude now? 

> > Well, you meight try to communicate before you release 
> > a patch. At least try. That does not limit your freedom, right? 
> 
> I will send my (stable) patches meant as a suggestion for a next release
> first to you, promised. :)

Ok. 
 
> > <quote source="http://www.gnu.org/licenses/why-not-lgpl.html">
> > The GNU Project has two principal licenses to use for libraries. One
> > is the GNU Library GPL; the other is the ordinary GNU GPL. The 
> > choice of license makes a big difference: using the Library GPL
> > permits use of the library in proprietary programs; using the
> > ordinary GPL for a library makes it available only for free programs. </quote>
> 
> Thank you for this hard-to-find link! Was the reason to stick to this
> license driven by the thought that someone would want to _include_
> JUnitDoclet into some proprietary products? Or was it merely to allow
> people to use (the free) JUnitDoclet to generate tests for their
> (unfree) proprietary program?

Maybe a bit of both and some other reasons?

> btw, you're welcome for the hint with the sf.net patches. I only find it
> sad that the whole menu entry has disappeared since you removed my patch
> from public! :) 

You helped me to decide, we would rather make a minor release
then provide a patch. Whether or not the patches are public is
just an option in the admin pages. Since we won't use it, I turned 
it off. Your patch is not gone, but provided to the team only. 

So there won't be a buggy patch on our project again.
As you've sad: There are better things to do, than writing novels.

> ps: your nice xml style for the quote brings my to another suggestion:

Yes, I have seen what projects you are involved with. 

Properties may not be the coolest thing, but they 
are installed where Java is installed. When they 
go XML, JUnitDoclet will. 

Regards,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

Re: [Junitdoclet-users] exception handling patch (bugfix)

[Nicola F. <nic...@va...>]

hi steffen

On Sun, 2003-04-06 at 22:10, ste...@ob... wrote:
> The tests passed when we released. And they passed a minute 
> ago. Maybe you've changed something else?

Hm, gotta fix that the next time I play around with it.

> Ever thought about encapsulation? What do you think 
> of a program spreading IllegalPriceExceptions and the 
> knowledge to handle them all over the application? 
> (I'd like to suggest a book: "The Pragmatic Programmer" 
> or "Der Pragmatische Programmierer" if you prefer a 
> german translation.)

I fully agree that such an IllegalPriceException should only be thrown
to an object directly accessing the setPrice() method and be caught at
the caller (the caller might decide to throw another, more general
exception [generally] then to _his_ caller if it was his caller's
fault).

And yes, I am fully capable of reading English books. thank you. :) And
besides, I also fully agree that wizards are evil (at least most of
them). Isn't JUnitDoclet a wizard? Hm.

> > That maybe have been the way it worked until now. 
> 
> Your statement does not sound like freedom to me.

Might be new for you: Freedom != Holidays

> Begging? Ever heard of feature requests?

Surely, but I have the feeling that even tough you honor a request, it's
still the team leader that decides which suggestions are finally
implemented (which is ok, besides). 

But for me writing what I need _is_ an option, so I use it when I have
the freedom (and time :). Otherwise, I gladfully write some feature
requests... :)

> Releasing buggy "patches" may be freedom to you, but is
> irritating to other users of JUnitDoclet (since they meight
> have difficulties to differenciate between the source of a 
> patch. I wouldn't even bothered, if your first patch would 
> have been working.

Sorry for that. To err is human.

> It's not my ego, that was hurt. If only one other user applied 
> your patch, he/she meight think different about our tool now. 
> That is, what I don't like.

Do you know the Compaq FAQ entry explaining "where the Any-key" is? Some
people never get it. Some people just shouldn't program (maybe me
included - but who else would then get the work done? :).

> Well, you meight try to communicate before you release 
> a patch. At least try. That does not limit your freedom, right? 

I will send my (stable) patches meant as a suggestion for a next release
first to you, promised. :)

> <quote source="http://www.gnu.org/licenses/why-not-lgpl.html">
> The GNU Project has two principal licenses to use for libraries. One
> is the GNU Library GPL; the other is the ordinary GNU GPL. The 
> choice of license makes a big difference: using the Library GPL
> permits use of the library in proprietary programs; using the
> ordinary GPL for a library makes it available only for free programs. </quote>

Thank you for this hard-to-find link! Was the reason to stick to this
license driven by the thought that someone would want to _include_
JUnitDoclet into some proprietary products? Or was it merely to allow
people to use (the free) JUnitDoclet to generate tests for their
(unfree) proprietary program?

btw, you're welcome for the hint with the sf.net patches. I only find it
sad that the whole menu entry has disappeared since you removed my patch
from public! :) 

regards
nicola

ps: your nice xml style for the quote brings my to another suggestion:
why not use XML as configuration format for JUnitDoclet? Fact is,
properties-files are ugly and some buzzwords like XML and maybe XPath
(or what is it called today) would surely frehen intereset in
JUnitDoclet, don't you think?

Re: [Junitdoclet-users] exception handling patch (bugfix)

[<ste...@ob...>]

Hi Nicola,

> > The update frequency of JUnitDoclet is not as high as 
> > in other projects, but there is good news in that:
> > 
> >   Don't touch a running system (if it's not nessecary).
> 
> I deemed it necessary. And luckily I have other things to do than
> writing novels - ...

;-)

> No seriously, JUnitDoclet does a wonderful job, but needs change quite
> badly IMO. Important classes are very big (talking about
> DefaultTestingStrategy), and I have not encountered one exception in the
> whole project - everything is done with return values, even errors are
> reported back this way. clearly not that elegant, but works admittedly. 

There are things that need refactoring. True.
 
> > What I don't enjoy in that much detail is a stream of 
> > untested patches, that make our software appear 
> > unstable. To be forced to react on this issue takes 
> 
> Are you afraid of people contributing code and the fact that you cannot
> control what exactly floats around (speaking of patches)? I understand
> up to a certain degree. 

I'm glad you wrote that.

> > Before we release a new version we run a lot of tests.
> > (Testing before the user does, isn't JUnit all about that?)
> 
> 100% ack. and why do 8 of your 105 tests fail constantly, even without
> having touched the code? :) 

The tests passed when we released. And they passed a minute 
ago. Maybe you've changed something else?

> btw, with my patch the exact same 8 tests still fail. is this success?
> ;) 

Not exactly.
   
> > With respect to the goal you try to achive:
> > Is testing an exception really worth complicating any 
> > tool? How often is it used in good programs? In my 
> 
> Sorry, no offence, but exceptions are an integral part of Java and if
> you don't think so, I have no problem with that either. But please let
> the other 95% Java programmers use exceptions, ok? :) 

Sure you can use them. 
 
> > opinion exceptions should be used only in exceptional 
> > cases. So there is very little of them. Right?
> 
> Exactly. And what do you do, if (for example) somebody tries to set a
> negative price on a product? Business as usual? I'd throw them a
> IllegalPriceException right in the face! 

Well, I don't. But I would let the user know too.

> Generally speaking: Programming C in Java is certainly possible, but
> it's like speaking English with French accent. Works, but is suboptimal.

I don't have to use something just because it's there. 
I use it, when I see fit.

Ever thought about encapsulation? What do you think 
of a program spreading IllegalPriceExceptions and the 
knowledge to handle them all over the application? 
(I'd like to suggest a book: "The Pragmatic Programmer" 
or "Der Pragmatische Programmierer" if you prefer a 
german translation.)

> You can check out the exact behavior for yourself, if you are
> interested.

I will look at it later, but I will.
 
> > This email is not ment as an offense. You like our tool,
> > you use it, you spent time to add something which 
> > seems usefull to you. You even shared your idea.
> > That is Open Source. Thank you.
> 
> It is interesting how your email has changed attitude in itself (when
> comparing the first dismissive lines you wrote with this quite nice
> paragraph at the end). 

I didn't change it, while you where reading. ;-)
 
> And yes, that's the way open source works. You don't have to
> like my patches (what the hell reminds me now of Linus? :), but
> I don't have hold back my patches either. After all, open source is
> about freedom, right?

Freedom is important. 

Open Source is about cooperation on behalf of usefull software.
 
> > All I ask is a little bit more testing before someone sends
> > out a message like you did. If someone has an idea to 
> > improve our tool, please send an email to 
> > jun...@ob.... We'll be more than happy to 
> 
> That maybe have been the way it worked until now. 

Your statement does not sound like freedom to me.

> You have to accept that
> there are also creative people out there using the freedom you gave to them
>  - they build their dreams with their own hands and don't have to beg.

Begging? Ever heard of feature requests?

> I certainly won't send bother you with an email if I see that the change 
> is no more than 2-3 hours worth of programming and so can be done by me...

That's ok. You've got the source for that.

Releasing buggy "patches" may be freedom to you, but is
irritating to other users of JUnitDoclet (since they meight
have difficulties to differenciate between the source of a 
patch. I wouldn't even bothered, if your first patch would 
have been working.
 
> > discuss that. And if it seems usefull to us too, it may 
> > even make it into the next release (as do other user 
> > suggestions like configurations for indent levels and 
> > accessor prefixes). 
> 
> I assume I stepped on your toes - I am sorry for that. 

It's not my ego, that was hurt. If only one other user applied 
your patch, he/she meight think different about our tool now. 
That is, what I don't like.

> I am however not
> sorry for my belief in open, direct & fast communication - so I still
> think this patch got out the right time.

Well, you meight try to communicate before you release 
a patch. At least try. That does not limit your freedom, right? 
I guess my responses have been open, direct & fast enough.

> If you don't like my patch being published on sf.net, then drop me a
> line and delete it, so I can put it on my website.

I've made the patches available to a smaller group already. 
If you let me know your website, I meight have a look at it.

> One question: why did you chose the LGPL as license and not the GPL?
> Using GPL software for commercial software engineering is perfectly
> legal - or is there another reason?

<quote source="http://www.gnu.org/licenses/why-not-lgpl.html">
The GNU Project has two principal licenses to use for libraries. One
is the GNU Library GPL; the other is the ordinary GNU GPL. The 
choice of license makes a big difference: using the Library GPL
permits use of the library in proprietary programs; using the
ordinary GPL for a library makes it available only for free programs. </quote>


Regards,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

Re: [Junitdoclet-users] exception handling patch (bugfix)

[Nicola F. <nic...@va...>]

hello steffen

On Sun, 2003-04-06 at 18:25, ste...@ob... wrote: 

[..snipped dismissive rant..] 
 
> The update frequency of JUnitDoclet is not as high as 
> in other projects, but there is good news in that:
> 
>   Don't touch a running system (if it's not nessecary).

I deemed it necessary. And luckily I have other things to do than
writing novels - because then I'd refactored JUnitDoclet so nobody would
have recognized it again. 

No seriously, JUnitDoclet does a wonderful job, but needs change quite
badly IMO. Important classes are very big (talking about
DefaultTestingStrategy), and I have not encountered one exception in the
whole project - everything is done with return values, even errors are
reported back this way. clearly not that elegant, but works admittedly. 

> What I don't enjoy in that much detail is a stream of 
> untested patches, that make our software appear 
> unstable. To be forced to react on this issue takes 

Are you afraid of people contributing code and the fact that you cannot
control what exactly floats around (speaking of patches)? I understand
up to a certain degree. But it is still your group releasing official
releases - so nobody (mentally sane) will complain about a non-official
patch not working correctly.

> away time from developing the tool. (I admit, in the 
> last few months I've been busy with other topics, but 
> now some of my time is for JUnitDoclet again. So 
> the statement is true.)

Very glad to hear that. 

> Before we release a new version we run a lot of tests.
> (Testing before the user does, isn't JUnit all about that?)

100% ack. and why do 8 of your 105 tests fail constantly, even without
having touched the code? :) 

btw, with my patch the exact same 8 tests still fail. is this success?
;) 
  
> With respect to the goal you try to achive:
> Is testing an exception really worth complicating any 
> tool? How often is it used in good programs? In my 

Sorry, no offence, but exceptions are an integral part of Java and if
you don't think so, I have no problem with that either. But please let
the other 95% Java programmers use exceptions, ok? :) 

> opinion exceptions should be used only in exceptional 
> cases. So there is very little of them. Right?

Exactly. And what do you do, if (for example) somebody tries to set a
negative price on a product? Business as usual? I'd throw them a
IllegalPriceException right in the face! 

Generally speaking: Programming C in Java is certainly possible, but
it's like speaking English with French accent. Works, but is suboptimal.

> Don't test RuntimeExceptions if you don't throw them 
> (and you should't throw them) ! 

I have to admit that my example was kind of confusing. The patch only
generates additional code if there _are_ exceptions declared to be
thrown, and only then tests only those.

You can check out the exact behavior for yourself, if you are
interested.

> IMHO there is not only "not enough testing" there is 
> also a "to much test code" when the real tests get 
> hidden behind a cloud of meaningless, generated code.

100% ack again.

> Actually that is what some of the other test geneators 
> do: They claim to think on behalf of the developer and 
> produce nice, compilable clouds.

mine are not even compilable, sniff. :) well, I put my thinking into
code. And if someone does not like my thinking, he's better without my
patch. It was never intended being different.

> JUnitDoclet meight generate some kind of tests for non
> RuntimeExceptions in the future but not now. As our
> software develops in iteratations, there are features 
> that are much more important. Those will even serve as 
> a better foundation for testing exceptions by preventing 
> clouding the tests. I hope you will agree when the next 
> release is out, even if exceptions are not adressed.

I will certainly take a look at the new release.

> This email is not ment as an offense. You like our tool,
> you use it, you spent time to add something which 
> seems usefull to you. You even shared your idea.
> That is Open Source. Thank you.

It is interesting how your email has changed attitude in itself (when
comparing the first dismissive lines you wrote with this quite nice
paragraph at the end). 

And yes, that's the way open source works. You don't have to
like my patches (what the hell reminds me now of Linus? :), but
I don't have hold back my patches either. After all, open source is
about freedom, right?

> All I ask is a little bit more testing before someone sends
> out a message like you did. If someone has an idea to 
> improve our tool, please send an email to 
> jun...@ob.... We'll be more than happy to 

That maybe have been the way it worked until now. You have to accept that
there are also creative people out there using the freedom you gave to them
 - they build their dreams with their own hands and don't have to beg.
I certainly won't send bother you with an email if I see that the change 
is no more than 2-3 hours worth of programming and so can be done by me...

> discuss that. And if it seems usefull to us too, it may 
> even make it into the next release (as do other user 
> suggestions like configurations for indent levels and 
> accessor prefixes). 

I assume I stepped on your toes - I am sorry for that. I am however not
sorry for my belief in open, direct & fast communication - so I still
think this patch got out the right time.

If you don't like my patch being published on sf.net, then drop me a
line and delete it, so I can put it on my website.

One question: why did you chose the LGPL as license and not the GPL?
Using GPL software for commercial software engineering is perfectly
legal - or is there another reason?

regards
nicola

Re: [Junitdoclet-users] exception handling patch (bugfix)

[<ste...@ob...>]

Hi Nicola,

> first of all, the patch sent out yesterday had a pretty dumb bug, which
> this patch solves.

Relax. 

Think.

Did you check your patch this time?




Really? 




The update frequency of JUnitDoclet is not as high as 
in other projects, but there is good news in that:

  Don't touch a running system (if it's not nessecary).

Well, actually some users sent me suggestions to
improve JUnitDoclet. That is highly welcome and their
contributions will be in the next release. I love that.

What I don't enjoy in that much detail is a stream of 
untested patches, that make our software appear 
unstable. To be forced to react on this issue takes 
away time from developing the tool. (I admit, in the 
last few months I've been busy with other topics, but 
now some of my time is for JUnitDoclet again. So 
the statement is true.)

Before we release a new version we run a lot of tests.
(Testing before the user does, isn't JUnit all about that?)
There is always a chance for one more bug, but we do 
a lot to make it a small chance.
Please, at least try the same with anything you release.
 
With respect to the goal you try to achive:
Is testing an exception really worth complicating any 
tool? How often is it used in good programs? In my 
opinion exceptions should be used only in exceptional 
cases. So there is very little of them. Right?

Don't test RuntimeExceptions if you don't throw them 
(and you should't throw them) ! 
Just one example: There are so many ways you can 
run out of memory... you test for that with other tools, 
better suited for that purpose.

One major design goal of JUnitDoclet is:
  predictable behaviour

This means: It is better to do nothing and point to the 
missing part, than doing something which is sometimes 
wrong.

IMHO there is not only "not enough testing" there is 
also a "to much test code" when the real tests get 
hidden behind a cloud of meaningless, generated code.
Actually that is what some of the other test geneators 
do: They claim to think on behalf of the developer and 
produce nice, compilable clouds.

JUnitDoclet meight generate some kind of tests for non
RuntimeExceptions in the future but not now. As our
software develops in iteratations, there are features 
that are much more important. Those will even serve as 
a better foundation for testing exceptions by preventing 
clouding the tests. I hope you will agree when the next 
release is out, even if exceptions are not adressed.


This email is not ment as an offense. You like our tool,
you use it, you spent time to add something which 
seems usefull to you. You even shared your idea.
That is Open Source. Thank you.

All I ask is a little bit more testing before someone sends
out a message like you did. If someone has an idea to 
improve our tool, please send an email to 
jun...@ob.... We'll be more than happy to 
discuss that. And if it seems usefull to us too, it may 
even make it into the next release (as do other user 
suggestions like configurations for indent levels and 
accessor prefixes). 
 
Keep on testing.

Regards,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

[Junitdoclet-users] exception handling patch (bugfix)

[Nicola F. <nic...@va...>]

hello 

first of all, the patch sent out yesterday had a pretty dumb bug, which
this patch solves.

so if you want to play with it, be sure to apply this one (altough the
older won't rm -rf your machine).

and for the attentive people out there: yes, the two code pieces in my
last mail did not fit together really well... :)

btw: is anyone interested in writing a real Eclipse plugin for
JUnitDoclet? While I myself don't have enough time to do that I'd be a
happy user of it... :)

regards
nicola

[Junitdoclet-users] exception handling patch

[Nicola F. <nic...@va...>]

hello JUnitDoclet-users, lovers & developers!

I hacked around a bit on JUnitDoclet and added a feature I really
missed: If a tested method throws an exception, tests should take
advantage of this. I've seen this being done with JuB
(http://jub.sourceforge.net/) and thought it was a really nice idea.

Consider the following method:

public void setPriceCode(int i) throws RuntimeException {
  if(i != CHILDRENS || i != REGULAR || i != NEW_RELEASE){
    throw new RuntimeException("illegal price code!");
  }
  else {
    priceCode = i;
  }
}

This patch makes JUnitDoclet generate automatically a test-method body
like this:

 public void testGetTitle() throws Exception {
    // JUnitDoclet begin method getTitle
    
    //insert code testing basic functionality
    try {
      movie.getTitle(null);
    } catch (Throwable e) {
      fail("Failed with:" + e);
    }

    //insert code triggering RuntimeException 
    try {	
      movie.getTitle(null);
      fail("Should raise RuntimeException");
    }
    catch (RuntimeException e) {
    }
    catch (Throwable e) {
      fail("Failed with:" + e);
    }
    
    //insert code triggering Exception 
    try {	
      movie.getTitle(null);
      fail("Should raise Exception");
    }
    catch (Exception e) {
    }
    catch (Throwable e) {
      fail("Failed with:" + e);
    }
    
    // JUnitDoclet end method getTitle
}

Of course, you have to add some bits & pieces to make the tests
compilable, but the main idea is here...

BTW, the whole thing works very well with multiple exceptions, too.

To apply the patch, get the source distribution, unzip the src.zip in it
and then execute this:

patch -p1 -u < JUnitDoclet_exeception_handling.patch

hope anyone will find this useful...

regards
nicola

Re: [Junitdoclet-users] Abstract classes and auto-fail

[<ste...@ob...>]

Hi Sam,

> 2. What do you think about starting off with a default fail in each test 
> method - otherwise you can easily miss implementing a test method and 
> thinking it passes.
Well, did you have the time to read the FAQ?
There are two good reasons for the current setting.

http://www.junitdoclet.org/faq.html#fail_not_default

Regards,

Steffen Gemkow

[Junitdoclet-users] Abstract classes and auto-fail

[Sam J. <ga...@yh...>]

Hi there,

Great project - I'm just really getting into using it.

Two things:

1. I'm very much looking forward to having methods from abstract classes 
being added automatically to extending classes test classes.

2. What do you think about starting off with a default fail in each test 
method - otherwise you can easily miss implementing a test method and 
thinking it passes.

CHEERS> SAM

[Junitdoclet-users] long input lines

[<ste...@ob...>]

A long classpath is never a good. 

It is an even worse, if you want to 
pass it to a batch file.

My suggestion is to shorten the classpath.

If that does not help, you meight adjust 
the batch and the settings of your IDE 
calling it. 

But the better way would be to use ANT
for the build process and include JUnitDoclet
there as well.

Regards,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

[Junitdoclet-users] "The input line is too long."-error when generating testcase

[Sakke W. <sak...@ne...>]

I set up JUnitDoclet 1.0.2 for integration with IntelliJ IDEA 3.0.1.
I have one project where i get the error "The input line is too long."
when trying to generate a testcase. Could the problem be that this projects
classpath is so long that the executed command becomes 1253 characters long?

Here's the whole output:

The input line is too long.
The syntax of the command is incorrect.
External tool 'Generate TestCase' completed with exit code 255



cheers,
Sakke Wiik
Software Engineer, NETikos Finland

[Junitdoclet-users] How to customerize the template?

[Lule C. <ll...@no...>]

Hi, I would like to know how to modify the template so that it will be able
to generate my customerized testcase code. I searched all the readme files
and the related doc but could not find where the template is.

Thanks for your help!


Louis

RE: [Junitdoclet-users] Customisation of output test classes

[<ste...@ob...>]

Hello John,

> I've been looking at HttpUnit the last couple of days and it will tie in
> fine with JUnitDoclet for me. I can let JUnitDoclet generate my classes,
> then use the HttpUnit APIs to access servlets etc. simply by modifying the
> generated code as my connection methods and communication to the servlet
> tests wouldn't be generated by JUnitDoclet anyway. HttpUnit tests also
> extend JUnit's TestCase so everything will work fine.

Did you try to come up with your own template?

Can you please send me (not the list) an example, 
of what you want your TestCases look like? 

Regards,

Steffen Gemkow

RE: [Junitdoclet-users] Customisation of output test classes

[John B. <joh...@ce...>]

Thanks for the reply Steffen.
I've been looking at HttpUnit the last couple of days and it will tie in
fine with JUnitDoclet for me. I can let JUnitDoclet generate my classes,
then use the HttpUnit APIs to access servlets etc. simply by modifying the
generated code as my connection methods and communication to the servlet
tests wouldn't be generated by JUnitDoclet anyway. HttpUnit tests also
extend JUnit's TestCase so everything will work fine.

John

-----Original Message-----
From: ste...@ob... [mailto:ste...@ob...]
Sent: 10 January 2003 15:42
To: John Bourke
Cc: jun...@li...
Subject: Re: [Junitdoclet-users] Customisation of output test classes


John,

thanks for your question. 

> Is it possible to configure the output, say if I wanted my test class to
> extend something other than JUnits TestCase. I'm thinking this so I could
> tie in to HttpUnit also.

Sure you can extend your test classes from different base classes.

The current use of JUnit's TestCase is defined as part of 
the template. There "TestCase" is placed between markers.

You can
  a) modify the extend statement of your test classes. 
   Make them extend from different base classes (for 
  example MyTestCaseBase) on an individual basis

  b) also have your test case implement an interface
  (It is common to have sets of constants to be declared 
   in separate interface. Every class implementing that 
   interface then is aware of the constants and can use 
   them in a convinient way.) --- You didn't ask for interfaces,
   I just tell anyway because it fits in here. 

  c) create your own template, if you want to change 
  the superclass of _all_ your test cases.

I've been thinking about generating for HttpUnit / Cactus.
It won't be difficult to extend JUnitDoclet for that, but 
right now not everything for Cactus can be generated. 
(it's the beginXYZ and endXYZ that won't shop up). 
I guess, we will provide a variable for that XYZ very soon.

Maybe you can provide an example, how you would 
like the generated classes to look like. 

Regards,

Gruesse,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

Re: [Junitdoclet-users] how to get tests for implementations in abstract classes?

[Thomas L R. <tl...@us...>]

Steffen Gemkow <ste...@ob...> 01/14/2003 02:52 AM
> at the moment JUnitDoclet can not generate tests for abstract
> classes. But it will in the next version. We know how we do it, we
> just didn't have the time.

I know how that goes :-)

> I guess it will be a month until you can get a new version.

OK. I can hack away meanwhile.

[Junitdoclet-users] how to get tests for implementations in abstract classes?

[Thomas L R. <tl...@us...>]

Can JUnitDoclet (JUD) be made to generate tests for methods in
abstract classes? What I mean:

I have code resembling the following:

abstract class Foo {
  void implementedMethod() { /* ... */ } // has implementation
  abstract void abstractMethod();        // doesn't
}

class FooBar extends Foo {
  void abstractMethod() { /* ... */ } // implements Foo.abstractMethod
}

class FooBaz extends Foo {
  void abstractMethod() { /* ... */ } // implements Foo.abstractMethod
}

I run JUD, and I get

class FooBarTest {
  void testAbstractMethod() { /* ... */ }
}

class FooBazTest {
  void testAbstractMethod() { /* ... */ }
}

but I don't get a testImplementedMethod() in any of FooTest,
FooBarTest, or FooBazTest. Is this a bug? or can JUD be made to
generate test stubs for methods implemented in abstract classes?

Apologies if this is a FAQ, but I didn't see it at

http://www.junitdoclet.org/faq.html

Re: [Junitdoclet-users] Customisation of output test classes

[<ste...@ob...>]

John,

thanks for your question. 

> Is it possible to configure the output, say if I wanted my test class to
> extend something other than JUnits TestCase. I'm thinking this so I could
> tie in to HttpUnit also.

Sure you can extend your test classes from different base classes.

The current use of JUnit's TestCase is defined as part of 
the template. There "TestCase" is placed between markers.

You can
  a) modify the extend statement of your test classes. 
   Make them extend from different base classes (for 
  example MyTestCaseBase) on an individual basis

  b) also have your test case implement an interface
  (It is common to have sets of constants to be declared 
   in separate interface. Every class implementing that 
   interface then is aware of the constants and can use 
   them in a convinient way.) --- You didn't ask for interfaces,
   I just tell anyway because it fits in here. 

  c) create your own template, if you want to change 
  the superclass of _all_ your test cases.

I've been thinking about generating for HttpUnit / Cactus.
It won't be difficult to extend JUnitDoclet for that, but 
right now not everything for Cactus can be generated. 
(it's the beginXYZ and endXYZ that won't shop up). 
I guess, we will provide a variable for that XYZ very soon.

Maybe you can provide an example, how you would 
like the generated classes to look like. 

Regards,

Gruesse,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

[Junitdoclet-users] Customisation of output test classes

[John B. <joh...@ce...>]

Folks,
 
Is it possible to configure the output, say if I wanted my test class to
extend something other than JUnits TestCase. I'm thinking this so I could
tie in to HttpUnit also.
 
Regards,
 
John Bourke
Ireland

Re: [Junitdoclet-users] Support for Cactus

[<ste...@ob...>]

On 10 Dec 2002 at 17:35, Matt Raible wrote:

> I'm curious to know if there are any plans to support Cactus testcases
> or StrutsTest cases in the future.  My LoginServletTest extends
> ServletTestCase and I get the following warning then running
> junitdoclet: 

Right now, there are no such plans. We are quite busy in
our current projects. Maybe in a few month, when we can use 
it in another project...

> [javadoc] javadoc: warning - TestCase
> org.apache.webapp.actions.LoginServletTest is invalid. It's not
> overwritten.

This shows, there was a TestCase already. JUnitDoclet "thinks"
it is none of the TestCases _it_ generated (based on the incomplete markers 
in the file). So it is not owerwritten. There is no special
handling for Cactus, Struts or any other framework.

Regards,

Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...

RE: [Junitdoclet-users] Re: JUnit 3.8.1

[<ste...@ob...>]

On 10 Dec 2002 at 15:22, Matt Raible wrote:

> I have no specific reason for wanting 3.8.1 - I just saw a message
> yesterday (can't seem to find it now) that some syntax had changed in
> 3.8.1 and tests were easier to write now.  Just wondering so I could
> answer this question if it ever does come up.  I'm writing a sample app
> that demonstrates using Xdoclet, Struts, JUnitDoclet, Cactus and other
> tools to build a webapp and test it.

I guess you are refering to the standard constructor. Since 
JUnit 3.8.1 you don't need to pass a name to the constructor.
Java allows a class without explicit declared constructor if 
the superclass has a constructor without parameters. So you 
could skip writing a constructor in a TestCase _if_you_are_ 
_using_JUnit_3.8.1_only_. Please see JUnit docs for details. 

But the "old fashioned" constructors are working fine too.
JUnitDoclet does generate constructors in that way, so 
TestCases can be used with JUnit versions prior to 3.8.1.
I believe 3.7 is used quite often.

Regards,
 
Steffen Gemkow
--
ObjectFab GmbH
ste...@ob...