Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / September 2006

Tip: Looking for answers? Try searching our database.

Testing Java classes

Thread view: 
Lionel - 28 Sep 2006 00:41 GMT
Some may remember that I've asked about error checking not long ago.

As a follow up I have a question regarding testing. Let the class
UserClass contain the variable int userVariable such that a user enters
the value of userVariable and it is checked to be valid before the class
is constructed or before a method such as a setter method is called on
UserClass that alters the value of userVariable.

So, if it is assumed that the variable userVariable will always fall
between say 0 and 400 inclusive, what should our tests be on this class?
We check the boundaries obviously, but is it necessary to test the class
by attempting to set userVariable to say  -1 or 401? If so, what
behaviour would we expect?

Thanks

Lionel.
Dirk Michaelsen - 28 Sep 2006 07:12 GMT
Hi Lionel,

>So, if it is assumed that the variable userVariable will always fall
>between say 0 and 400 inclusive, what should our tests be on this class?
>We check the boundaries obviously, but is it necessary to test the class
>by attempting to set userVariable to say  -1 or 401? If so, what
>behaviour would we expect?

the usual tests are:

1. test the boundary legal values (0 and 400). The expected behaviour
ist that these values are accepted.

2. test the both first values outside the boundary (-1 and 401). The
expexted behaviour is that these values are not accepted.

3. test a value somewhere inside the legal boundaries, usually in the
middle of the legal range (eg. 199). The expected behaviour ist that
these values are accepted.

It is necessary to test values outside the boundaries to verify the
correct boundary checking. And it is useful to test a value from
inside the boundaries to ensure that not only the boundary values are
accepted.

cu
Dirk
Lionel - 29 Sep 2006 05:11 GMT
> Hi Lionel,
>
[quoted text clipped - 20 lines]
> inside the boundaries to ensure that not only the boundary values are
> accepted.

Ok, well I was talking about this before. How should the class behave if
the it gets a value that is out of bounds? Should it throw an exception,
the conclusion that I came to last time was that it wasn't necessary to
throw an exception.

Lionel.
Dirk Michaelsen - 29 Sep 2006 06:48 GMT
Hi Lionel,

>Ok, well I was talking about this before. How should the class behave if
>the it gets a value that is out of bounds? Should it throw an exception,
>the conclusion that I came to last time was that it wasn't necessary to
>throw an exception.

maybe I missed some posts...

I think, throwing an exception depends on the context of the method.

If you want to calculate a value in a mathematical method it is useful
to throw something like IllegalArgumentsException when illegal values
are entered. If, on the other hand, you want to generate an object
using the argument you may consider to return <null> when an illegal
argument is entered to signal that something goes wrong.

I try to awoid throwing exceptions wherever possible because of the
overhead they require on the callers side.

cu
Dirk


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.