The Artima Developer Community
Sponsored Link

News & Ideas Forum (Closed for new topic posts)
JUnitDoclet 1.0.1 Released

12 replies on 1 page. Most recent reply: Apr 18, 2004 5:44 AM by Steffen Gemkow

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 12 replies on 1 page
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

JUnitDoclet 1.0.1 Released Posted: Nov 4, 2002 12:31 PM
Reply to this message Reply
Advertisement
Steffen Gemkow and friends have release JUnitDoclet 1.0.1 under the LGPL, which uses JavaDoc to generate skeletons for JUnit TestCases.

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

Here's an excerpt from the JUnitDoclet documentation:

JUnitDoclet works as a plug-in for SUN?s JavaDoc tool but instead of generating HTML documentation it generates test classes and methods. For every public method of every class in the application a JUnit TestCase is created. In addition all TestCases of a package and its subpackages are added to a JUnit TestSuite.

Do you think you would find a tool like this useful?


Henry J Cooper

Posts: 2
Nickname: hjcooper
Registered: Nov, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 5, 2002 8:10 AM
Reply to this message Reply
i think it may be useful when you have existing code that you want to add unit tests to. Not useful if you develop new code test-first as should be done in most cases.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 5, 2002 4:46 PM
Reply to this message Reply
> i think it may be useful when you have existing code that
> you want to add unit tests to. Not useful if you develop
> new code test-first as should be done in most cases.

I often add write tests after the fact rather than before, but even so the problem I have is not so much the skeleton of the tests but the flesh. What would be more useful to me, I think, would be some shortcut keystrokes in my IDE that would generate a empty skeleton test method for a particular method name, or generate an empty skeleton TestCase class for a particular class being tested. That way the skeleton is created right before I write the meat. I would rather not have 1000 empty skeleton methods not doing anything, but then again, I haven't tried the JUnitDoclet tool.

Steffen Gemkow

Posts: 6
Nickname: sgemkow
Registered: Nov, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 6, 2002 3:25 AM
Reply to this message Reply
> i think it may be useful when you have existing code that
> you want to add unit tests to. Not useful if you develop
> new code test-first as should be done in most cases.

Henry,

I prefer to write tests before the application as well
and I don't like not compilable code. (As some people
have with their way of Test First.)

That's why I write an empty (but compilable) method in
the application first, use JUnitDoclet to provide the
skeleton, fill in the test(s), see it (them) fail,
make them pass and finally refactor.

It's not to different from other approaches, right?

I receive a lot of complaints from people like "When I
start a test I don't know what methods I need." Well,
they are doing featureoriented testing. JUnitDoclet is
helping with structure oriented tests, but does not
prevent you from writing your own tests.

Both ways (structure oriented and funktional) have
major benefits, why skip one of them?

And because of the help with Refactoring JUnitDoclet
provides, it is very easy to rename, introduce or remove
methods. No need to think to much upfront about signatures
and stuff. Not much of a difference, except you have the
full power of your IDE to help you.


If someone did no unit testing before, JUnitDoclet is
an easy way to get he/she to start with it. And later
they may do Test-First with it. I know some people who
say, they would suggest to drop JUnitDoclet once you
eached that point. I would not do that, but that's
just me. I'm kind of addicted to JUnitDoclet.

Please see the features we plan to implement in the
next version. Tests for interfaces and abstract
classes that are applied to implementing classes,
More than one test method per application method, ...

Regards,

Steffen Gemkow

Steffen Gemkow

Posts: 6
Nickname: sgemkow
Registered: Nov, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 6, 2002 3:42 AM
Reply to this message Reply
Bill,

> I often add write tests after the fact rather than before,
> but even so the problem I have is not so much the skeleton
> of the tests but the flesh.

My experience is, that if you have an empty test method,
it is just so easy to check a few little things anyway.
You _will_ do it. And there you go. :-)

Please go to the FAQ, there is a statement why we did
not use "fail();" as the default implementation of
tests. You may find that interesting too.

> What would be more useful to
> me, I think, would be some shortcut keystrokes in my IDE
> that would generate a empty skeleton test method for a
> particular method name, or generate an empty skeleton
> TestCase class for a particular class being tested. That
> way the skeleton is created right before I write the meat.

That is kind of what I do. Ever tried to install
JUnitDoclet as external tool? Examples for Eclipse,
IDEA and ANT are part of version 1.0.1 .

> I would rather not have 1000 empty skeleton methods not
> doing anything, but then again, I haven't tried the
> JUnitDoclet tool.
With JUnitDoclet you may get many empty test methods,
that is true. But over time they may not stay that way.
(See above and FAQ)

But there is more:
If your classes have Bean like accessors, JUnitDoclet
will generate some default tests for them. Accessors
don't seem to be much of a risk, but because of
programing with Copy/Paste we all had our share of
"a method getName() returning firstname instead". ;-)
You get this tests for free and find this stupid
errors right away.

Maybe all this inspired you to further evaluate
JUnitDoclet.

Regards,

Steffen Gemkow

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 12, 2002 5:53 PM
Reply to this message Reply
> I receive a lot of complaints from people like "When I
> start a test I don't know what methods I need." Well,
> they are doing featureoriented testing. JUnitDoclet is
> helping with structure oriented tests, but does not
> prevent you from writing your own tests.
>
> Both ways (structure oriented and funktional) have
> major benefits, why skip one of them?
>
How do you define the difference between structure-oriented and feature-oriented testing?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 12, 2002 6:01 PM
Reply to this message Reply
> Please go to the FAQ, there is a statement why we did
> not use "fail();" as the default implementation of
> tests. You may find that interesting too.
>
I just read this FAQ item, which is here:

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

I understand better now the motivation for not having the empty tests contain a fail() method.

Steffen, did you ever consider having empty methods be commented out or start with "xtest" instead of "test" so they don't show up in the tests run count? I like the number of expected tests and total tests run count, and I think I'd prefer if those numbers didn't include empty auto-generated tests. Perhaps this could be yet another choice in the configuration of the tool.

Steffen Gemkow

Posts: 6
Nickname: sgemkow
Registered: Nov, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 13, 2002 1:58 AM
Reply to this message Reply
> > Both ways (structure oriented and funktional) have
> > major benefits, why skip one of them?
> >
> How do you define the difference between
> structure-oriented and feature-oriented testing?

I consider tests directly related to exactly one
code unit (method or class or package) to be structure-
oriented. JUnitDoclet is helping you with generating
them and it will bring the structure of tests up to
date after refactoring.

The functional tests are not assignable to a specific
portion of the code. They desribe more or less a use
case and may involve very different parts of the
application. I'm sure they are very helpful, and I
write some of them too. (You can easy extend TestCases
and TestSuites generated by JUnitDoclet with tests
you wrote manually.)

I just don't believe we should rely on functional
tests only. And I'm lazy, so I use JUnitDoclet to
provide a place to write tests that I can relate to
some part of the code. For everything else, I still
can (and do) write a feature-oriented test manually.

There are developers who base Test Driven Development
on functional-/feature-oriented tests. They type
the TestCase first, even if it's not compilable at
that time, because there is no application method to
test. This way they write down their intention
without beeing "limmited" to the current methods of the
application. Tools like IDEA and Eclipse support to
generate those missing methods to the application.
Unfortunately the test methods may involve almost any
part of an the application. And therefore I would have
light difficulties to organize the tests in suites.

I've seriously tried that approach as well, but I like
the structure oriented tests much more. I use JUnitDoclet
for Test Driven Development, but I type the application
method first to give JUnitDoclet something to work on.
After all, both ways of TDD you may change the name or
the signature of a method, during writing the test.
So the test and the skeleton of application method
get written in parallel. It's just this old, single
threaded keyboard, that makes one thing appear first.
;-)

Comparing both "flavors" of TDD I value the documentation
aspect of structure-oriented tests more then the
intentional thing is helping me. But that's just me,
others may have different experiences. If I look at
my code in three years from now, I'll go to the test
method first to understand how some method should
work. I like that.

I hope this kinda long explanation of the statement
in my former posting is helping someone.

Regards,

Steffen

Steffen Gemkow

Posts: 6
Nickname: sgemkow
Registered: Nov, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 13, 2002 2:21 AM
Reply to this message Reply
> Steffen, did you ever consider having empty methods be
> commented out or start with "xtest" instead of "test" so
> they don't show up in the tests run count? I like the
> number of expected tests and total tests run count, and I
> think I'd prefer if those numbers didn't include empty
> auto-generated tests. Perhaps this could be yet another
> choice in the configuration of the tool.

I guess, you have read this document:

http://www.junitdoclet.org/getting_started.txt

Future versions of JUnitDoclet may do some reporting on empty test methods.

Any tool could rename empty test methods to "xtest*" only if it is running. Because I use JUnitdoclet as external tool in my IDE as well, I often fill test methods after that and want to execute the test right away. The "x" would be a pain for me.

I'd made the experience, that empty test methods don't stay empty very long. So don't try to control yourself or your fellow developers to much. Some simple reporting would do just fine, I believe.

From my point of view the number of tests does not say much about the real test coverage. If that's what you are interested in, there are very good tools for it out there...

Regards,

Steffen

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: JUnitDoclet 1.0.1 Released Posted: Nov 13, 2002 2:21 AM
Reply to this message Reply
> I hope this kinda long explanation of the statement
> in my former posting is helping someone.
>
Well, it helps me.

I guess I don't usually consider use case tests as unit tests. To me the "unit" in unit test is some code structure unit, like a class or method, not a functional or conceptual unit like a use case.

Steffen Gemkow

Posts: 6
Nickname: sgemkow
Registered: Nov, 2002

JUnitDoclet 1.0.2 Released Posted: Nov 29, 2002 3:53 PM
Reply to this message Reply
Hi everyone,

We've just released JUnitDoclet 1.0.2.
It's all about bugfixes. Upgrading is recommended.

Regards,

Steffen

samymohan

Posts: 2
Nickname: samymohan
Registered: Jan, 2004

Re: JUnitDoclet 1.0.1 Released Posted: Jan 15, 2004 5:29 AM
Reply to this message Reply
Hi
Iam using Jdeveloper9.0.3.2 for developing java application.can you please guide me to configure JunitDoclet with it and steps to follow to run the Junit test cases

Regards
Samymohan

Steffen Gemkow

Posts: 6
Nickname: sgemkow
Registered: Nov, 2002

Using JUnitDoclet with other IDEs Posted: Apr 18, 2004 5:44 AM
Reply to this message Reply
Hi,

JUnitDoclet is not bound to one or two IDEs, that's the good news. Unfortunately we don't have the ressources to check out each IDE.

But modern IDEs have some cool features that make it easy to work with JUnitDoclet and many other tools:
* The build process is using ANT.
* External programms can be called (with package/directory names and class/file names as parameters).

As long as an IDE supports either of those features, it is very easy to integrate JUnitDoclet. Please download the distribution, unzip it and see ./doc/ for examples.

Regards,

Steffen

Flat View: This topic has 12 replies on 1 page
Topic: Python and the Programmer Previous Topic   Next Topic Topic: Delegates, Components, and Simplexity

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use