Java Help - testing methods

Author

testing methods

Michael

2005-10-29, 9:56 pm

Hello all, I was wondering something. I am putting 4 methods into a class
called MyUtils. Can I test these methods to make sure they work; if I create
new new class files calling these methods. My question is , should it work
if I place all files in same directory.

Roedy Green

2005-10-30, 3:57 am

On Sun, 30 Oct 2005 01:01:01 GMT, "Michael" <mbialowas@shaw.ca> wrote,
quoted or indirectly quoted someone who said :

>Hello all, I was wondering something. I am putting 4 methods into a class
>called MyUtils. Can I test these methods to make sure they work; if I create
>new new class files calling these methods. My question is , should it work
>if I place all files in same directory.

In a simple case, your test method can be the main method of the class
you are testing with the body of the method enclosed in:
if ( DEBUGGING )
where DEBUGGING is a static final boolean. This code has a dual
purpose of exercising the methods and showing some sample uses and
expected outputs.

For more complex classes, you use a tool like Junit.

See http://mindprod.com/jgloss/testing.html

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Rhino

2005-10-30, 7:00 pm

"Michael" <mbialowas@shaw.ca> wrote in message
news:hXU8f.339123$1i.216931@pd7tw2no...
> Hello all, I was wondering something. I am putting 4 methods into a class
> called MyUtils. Can I test these methods to make sure they work; if I
create
> new new class files calling these methods. My question is , should it work
> if I place all files in same directory.
>
I agree with what Roedy has already said. I have done exactly what you're
talking about and tested these utility methods via both of the techniques
Roedy mentions and they worked very well for me.

In fact, I have quite a few different groups of utility methods so I put
each group into its own class. As a result, I have a GraphicUtils class for
utility methods that involve Graphics, a DateTimeUtils class for utility
methods involving the calculation of dates and times, FontUtils for utility
methods involving fonts, and so forth. I also have a MiscellaneousUtilities
class for everything that doesn't properly fit into any of the other Utility
classes. All of them belong to a package called
'mydomain.com.common.utilities'. When I bundle up my applications, the
applications are only distributed with the specific Utils classes that they
need, e.g. FontUtils and LogUtils. If I had put all of my utilities into a
single large class called Utils, I'd have to ship a large number of utility
methods most of which never got used. Instead, I ship a few smaller classes
of utilities, most of which DO get used.

One other thing: I think you'll find that you want to make your Utility
methods static. There is little value, as far as I can see, in having to
instantiate potentially dozens or hundreds of instances of your Utility
classes at runtime when a class containing static methods will do the job
just fine. If you look at classes like Math, you'll see that its methods are
static; I assume that is for the same reason as I just cited.

By the way, if you decide to check out JUnit, just so a Google search on
"JUnit tutorial" and you'll find plenty of hits describing how to use it. I
didn't find JUnit particularly intuitive to use at first but it actually
works quite well and isn't too hard to learn. It's also integrated into some
IDEs, like Eclipse, so you don't even have to download it or install it if
you use Eclipse since it's already there.

Rhino

Roedy Green

2005-10-30, 7:00 pm

On Sun, 30 Oct 2005 09:00:57 -0500, "Rhino"
<no.offline.contact.please@nospam.com> wrote, quoted or indirectly
quoted someone who said :

>One other thing: I think you'll find that you want to make your Utility
>methods static. There is little value, as far as I can see, in having to
>instantiate potentially dozens or hundreds of instances of your Utility
>classes at runtime when a class containing static methods will do the job
>just fine. If you look at classes like Math, you'll see that its methods are
>static; I assume that is for the same reason as I just cited.

Math is static because none of the methods require saving state. The
methods all do their thing purely with local variables. Thus the
class is thread-safe without any effort, and you don't need to think
about saving state for each thread.

Further the methods are all final because there is no thought of
extending say "sin". It makes no sense to change the meaning of any
of the mathematical primitive methods. If your class is like that,
then static is fine for it too.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Sponsored Links