> From: "Jim Jackl-Mochel" <jmochel@...>
> Subject: Unit Testing JDBC database code.
>
> In trying to make my unit tests very self contained I have
> come up against a
> small
> headache. In the case of those classes that read or
> manipulate a database
> via JDBC I
> would ideally like to create the database, manipulate it, and
> then remove
> the database.
>
> How have everybody else handled this sort of unit test ?
>
I have created java interfaces that encapsulate the queries I need to make.
The normal implementation of those interfaces is the code that knows about
JDBC, the schema, etc. My unit tests also implement those interfaces and
pretend to act like the database. They supply and accept the necessary data
and verify that the database is handled correctly. This also allows me to
mimic database errors.
See the "MockObject" threads on extremeprogramming@egroups.com. Also see
the book "Extreme Programming In Practice" by Jim Newkirk and Robert C.
Martin.
Robert C. Martin | "Uncle Bob" | Software Consultants
Object Mentor Inc. | rmartin@... | We'll help you get
PO Box 5757 | Tel: (800) 338-6716 | your projects done.
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python|
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
I get the following failure when executing my test case...
warning(junit.framework.TestSuite$1) "Cannot instantiate test case:
testStore"
What do I do wrong???
Thanx for help!
Pieter Janssens
Here a short version of my code...
public class DossierTest extends TestCase {
protected static ConnectionPool fConnectionPool;
private static String
fkDBSettingsFile=Parameters.getDBSettingsFile();
private Dossier
fDossier = new Dossier(null, "DossierType", null, null,
0, "WachtendeOpGodot");
/**
* Construct a new testcase for BeanTest
* @param name name of the testcase
*/
public DossierTest(String name) {
super(name);
}
/**
* Necessary to run testcase in a suite
*/
public static Test suite() {
return new TestSuite(DossierTest.class);
}
/**
* Run the test
* @param args program arguments
*/
public static void main (String[] args) {
junit.textui.TestRunner.run (suite());
}
/**
* Initialize the fields for the test
*/
protected void setUp() {
/* ...THE SETUP... */
}
/**
* Tests the method af <code>Dossier</code>
that stores the "dossier"
*/
public void testStore() {
/* ...THE TEST... */
}
}
I think, for this line to work...
return new TestSuite(DossierTest.class);
you need to have a constructor that takes no arguments.
Also, while I'm not sure by any means, it looks to me like your mixing
TestSuite "stuff" with TestCase stuff. I don't know that it won't work,
but I don't think I have suite() in any of my TestCases.
janssens.debom@... wrote:
>
> I get the following failure when executing my test case...
>
> warning(junit.framework.TestSuite$1) "Cannot instantiate test case:
> testStore"
>
> What do I do wrong???
>
> Thanx for help!
>
> Pieter Janssens
>
> Here a short version of my code...
>
> public class DossierTest extends TestCase {
> protected static ConnectionPool fConnectionPool;
> private static String
> fkDBSettingsFile=Parameters.getDBSettingsFile();
> private Dossier
> fDossier = new Dossier(null, "DossierType", null, null,
> 0, "WachtendeOpGodot");
>
>
> /**
> * Construct a new testcase for BeanTest
> * @param name name of the testcase
> */
>
> public DossierTest(String name) {
> super(name);
> }
>
> /**
> * Necessary to run testcase in a suite
> */
>
> public static Test suite() {
> return new TestSuite(DossierTest.class);
> }
>
> /**
> * Run the test
> * @param args program arguments
> */
>
> public static void main (String[] args) {
> junit.textui.TestRunner.run (suite());
> }
>
> /**
> * Initialize the fields for the test
> */
>
> protected void setUp() {
> /* ...THE SETUP... */
> }
>
> /**
> * Tests the method af <code>Dossier</code>
> that stores the "dossier"
> */
>
> public void testStore() {
> /* ...THE TEST... */
> }
>
>
> }
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@...
on 12/2/00 8:41 AM, David Corbin at dcorbin@... wrote:
> I think, for this line to work...
>
> return new TestSuite(DossierTest.class);
>
> you need to have a constructor that takes no arguments.
>
> Also, while I'm not sure by any means, it looks to me like your mixing
> TestSuite "stuff" with TestCase stuff. I don't know that it won't work,
> but I don't think I have suite() in any of my TestCases.
It should be OK, but not strictly necessary, to have the suite() method
here. (The TestRunners will run a class without a suite() method in the
same way, as if the the "new TestSuite(Something.class)" was there.) The
extra suite() method might be nice if you wanted to do something different
with this class' suite(), or if you wanted to aggregate classes in an
AllTests sort of class:
suite.addTest(MyTest.suite());
suite.addTest(MyOtherTest.suite());
instead of
suite.addTest(new TestSuite(MyTest.class));
suite.addTest(new TestSuite(MyOtherTest.class));
The string-argument constructor should be OK too, in my experience.
>> private static String
>> fkDBSettingsFile=Parameters.getDBSettingsFile();
>> private Dossier
>> fDossier = new Dossier(null, "DossierType", null, null,
>> 0, "WachtendeOpGodot");
All of that said, I'm not sure what would be the problem. Is there some
kind of exception being thrown during the initialization of fkDBSettingsFile
or fDossier? Is there a different message if there's a problem during
setUp()?
---
Ben Schroeder
schroeder@...
janssens.debom@... wrote:
> I get the following failure when executing my test case...
>
> warning(junit.framework.TestSuite$1) "Cannot instantiate test case:
> testStore"
>
> What do I do wrong???
CAVEAT: I'm a real newbie with Java and I've just started playing w/JUnit,
but
here's what I did...
I took your file, commented out the local data members and tried to build it
under
JBuilder4 (which I have setup with JUnit). I had to add these three lines
from one
of my test files and it built and ran OK.
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
You code looks OK to me, maybe your environment is not setup correctly? Some
dumb questions are...
Have you tried building and running the sample code that comes with JUnit?
Do you have any other tests that work?
Do you have your class path setup correctly?
In JBuilder4, I have src.zip in the list of source paths for my project. I
have junit.jar
in my class path.
PCM (Paul Michali)
Carrier Voice Gateway Business Unit (CVGBU)
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone : (800) 572-6771 x 45817 (978) 244-5817 [direct]
Paging: (800) 365-4578 [voice] pcm@... [email page]
> Date: Fri, 1 Dec 2000 08:26:10 -0600
> From: "Robert C. Martin" <rmartin@...>
> > From: "Jim Jackl-Mochel" <jmochel@...>
> > Subject: Unit Testing JDBC database code.
> >
> > In trying to make my unit tests very self contained I have
> > come up against a small
> > headache. In the case of those classes that read or
> > manipulate a database via JDBC I
> > would ideally like to create the database, manipulate it, and
> > then remove the database.
> >
>
> I have created java interfaces that encapsulate the queries I need to make.
> The normal implementation of those interfaces is the code that knows about
> JDBC, the schema, etc. My unit tests also implement those interfaces and
> pretend to act like the database. They supply and accept the necessary data
> and verify that the database is handled correctly. This also allows me to
> mimic database errors.
>
> See the "MockObject" threads on extremeprogramming@egroups.com. Also see
> the book "Extreme Programming In Practice" by Jim Newkirk and Robert C.
> Martin.
You might also want to look at our paper from XP2000.
http://www.sidewize.com/company/mockobjects.pdf
P.S. Uncle Bob. Did I miss the announcement of your publication date?
Steve
> See the "MockObject" threads on extremeprogramming@egroups.com
Also see
> the book "Extreme Programming In Practice" by Jim Newkirk and
Robert C.
> Martin.
>
Where might one "see the book"? I can't find any information on it.
Thanks,
Chad
I'm writing an AppleScript version of jUnit and was wondering if
someone might be able to answer a question or
two that I've been pondering?
In AppleScript, "run", is a keyword so I wish to rename the
run() methods in the various objects that use it to
something else. According to "jUnit A Cook's Tour"
TestCase applies the "Command" Pattern. Does this mean
that the name of the "run()" method must remain very generic
such as "execute()" or "doIt()"? Or does the
"Command Pattern" implementation allow it to be made more
specific-expressive?
For example, would it be okay to change the method's name from
"run()" to something a little less generic,
such as shown below, yet not break the pattern?
inflict_stress()
conduct_tests()
incur_stress_and_lament about TestResult
(Note: "about" is an AppleScript labeled parameter keyword.)
Thanks,
Anthony
At 11:30 AM 12/3/00 , you wrote:
>For example, would it be okay to change the method's name from
>"run()" to something a little less generic,
>such as shown below, yet not break the pattern?
How about "runTestCases", for symmetry with Test's only other method,
"countTestCases"?
John Brewer
Jera Design
--- In junit@egroups.com, John Brewer <jbrewer@j...> wrote:
> How about "runTestCases", for symmetry with Test's only other
method,
> "countTestCases"?
If running Test cases is what the "run()" method ultimately does in
all the objects of the Framework, including
the various extensions and enhancements then that sounds like a good
name.
So, can I assume that a more expressive (and therefore less generic)
method name such as, "runTestCases",
does not break TestCase's application of the "Command
Pattern"? In other words, I wouldn't be creating a
misleading name by making this name change?
Was there a good reason why the original xUnit developers gave that
method such a generic name as
opposed to something like "runTestCases" in the first place?
Was there method to their madness or did they just fancy the word,
"run"?
Thanks,
Anthony
How about just leaving it as it is because lots of people use it that
way. The Mac version can use another name for the run() methods, but
that should be no general change backported into the Java version...
John Brewer wrote:
>
> How about "runTestCases", for symmetry with Test's only other method,
> "countTestCases"?
I am trying to find ideas of how to extend the test cases to html. We
have a java back end, and jsp which builds the final html. So how can
we build test cases for the jsp/html as well? If you have any ideas,
or know of other resources, I am very interested in them. This is one
of the main sticking points that my manager has in adopting XP as a
standard practice.
Thanks,
Colin
Hi,
here are new versions of JUnitX and XPTest with a lot of new features
people asked me to implement. And as well there is finally the big
tutorial on how to use the stuff. Go to
http://www.extreme-java.de
to get the new archives...it's all open source...
JUnit is a Java testing framework by Kent Beck and Erich Gamma. I
refactored and enhanced it to allow testing of private and protected
code. You even can test private inner class of a package private class
in another package ,)
After the religious discussion on extremeprogramming@egroups.com, I
need to say that you should test your application through public
interfaces and classes whenever possible. If you cannot cover important
code, you should think about testing protected code.
JUnitX also offers improved text und Swing UIs and a build system based
on Ant. So you can build the sources on nearly any plattform supporting
Java. As soon as JUnit gets it's own open-source project, I want to
contribute all my enhancements until JUnitX is no longer different.
XPTest is an integration of JUnitX into Together, the cool UML modelling
tool from http://www.togethersoft.com. XPTest saves you a lot of typing
by generating test cases, packages and proxies for JUnit(X).
And finally you can get the 'Advanced Java Testing' tutorial which
shows you how to combine Java, UML, JUnitX, XPTest, Ant and
Extreme Programming for successful software development.
Have fun and send me your feedback,
Andreas.
I came accross this Extension to Junit:
http://www.c2.com/cgi/wiki?HttpUnithttp://httpunit.sourceforge.net/
HttpUnit is a free, open source Java API for accessing
web sites without a browser, and is ideally suited for
automated unit testing of web sites when combined with
a Java unit test framework such as JUnit. It was designed
and implemented by Russell Gold.
At the JavaUnit Wiki:
http://www.c2.com/cgi/wiki?JavaUnit
I think it does testing from the client point of
view and only with HTML/Forms...but I thought I
would forward it for what it's worth. Please
let me know if you come up with any JSP testing
resources/solutions, as that will be very useful
for us as well.
Thanks,
Gidado
> -----Original Message-----
> From: crand@... [mailto:crand@...]
> Sent: Monday, December 04, 2000 3:27 PM
> To: junit@egroups.com
> Subject: [junit] test cases for html gui
>
>
> I am trying to find ideas of how to extend the test cases to html. We
> have a java back end, and jsp which builds the final html. So how can
> we build test cases for the jsp/html as well? If you have any ideas,
> or know of other resources, I am very interested in them. This is one
> of the main sticking points that my manager has in adopting XP as a
> standard practice.
>
> Thanks,
>
> Colin
>
>
>
> -------------------------- eGroups Sponsor
> -------------------------~-~>
> eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9699/0/_/_/_/975961659/
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>
>
>
I've been using JUnit to test my Java classes for a
few weeks now. I've reached a problem that others
have encountered as well.
Here's the problem:
I've been asked, by my team leader, to write what's
called an AbstractNavigator. It doesn't matter what a
Navigator is, the important point is that
AbstractNavigator is an abstract class. This abstract
class has a couple subclasses already (MDINavigator
and TabbedPaneNavigator), and more will be written in
the future.
We want to create unit tests (using JUnit, let's say
AbstractUnitTest) which will apply to any
AbstractNavigator. Herein lies the problem. I can't
actually test the AbstractNavigator because I can't
"have a(n)" AbstractNavigator since it's abstract.
Therefore, I need to test a subclass of the
AbstractNavigator, but currently, the only way I see
of doing that (making the AbstractUnitTest "have a"
MDINavigator) restricts the abstractedness of the unit
tests. The AbstractUnitTest could not be used without
recompiling, a step to be avoided.
Another method we've thought of is to add a method
"getNavigator" to the AbstractUnitTest which is called
from the TestCase setUp() method. This getNavigator
method would only be implemented by subclassing the
AbstractUnitTest class and would then return the
specific type of AbstractNavigator to be tested (i.e.
MDINavigator). The problem with this solution is that
the method of TestCase which returns the TestSuite is
static and therefore cannot be overridden...where to
go from here?
If anyone can give us any more information about this
kind of abstract unit testing, we would greatly
appreciate it.
Thanks,
CJ
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
Hi,
Sorry if this is a FAQ but I couldn't find it answered anywhere ...
Is it possible with JUnit 3.2 to order test methods, i.e. choose
which test method to execute first ?
For example :
public class MyTest extends TestCase
{
[...]
public void test2() {}
public void test1() {}
public static Test suite() {
return new TestSuite(MyTest.class);
}
}
I'd like to know for sure that test1() is called before test2().
Thanks.
Note: Of course, I could write :
public void testAll() {
test1();
test2();
}
but I don't like it much ...
--- In junit@egroups.com, Keith Ray <keith.ray@e...> wrote:
> How about changing the name 'run' to 'runTest'... It would be best if the
> SAME sources were available for Mac as well as other platforms.
>
As I mentioned before, the problem is that 'run' is a keyword in AppleScript so
giving 'run()' another name
would be better for the AppleScript version of xUnit.
> The Command Pattern example in the "Design Patterns" book actually uses the
> name "execute".
>
> My own implementation of the command pattern (used for GUI programming, not
> JUnit) uses "doIt", "undoIt", and "redoIt".
I noticed the examples and class diagrams in "Design Patterns", "The Design
Patterns Smalltalk Companion", and
"Java Design Patterns" all use very generic method names for this key method in
the command pattern. Other
than to maintain backwards compatibility (and continuity with other xUnits), is
there any other reason to keep it
so ambiguous?
Does not 'runTestCases' or 'incur_stress_andLament about TestResult' better
express the method's purpose?
Anthony
Ok, here are my 5 cents:
Why don't you ask a Factory to give you a list
of navigator types. After that get the navigator instances
from the factory one by one and test them.
You can get the factory and the list of instances
in a setUp() method. Write a test method for each kind
of test and run it on all instances known to the
factory.
Thats the way I would try it,
Andreas.
>
> I've been using JUnit to test my Java classes for a
> few weeks now. I've reached a problem that others
> have encountered as well.
> Here's the problem:
> I've been asked, by my team leader, to write what's
> called an AbstractNavigator. It doesn't matter what a
> Navigator is, the important point is that
> AbstractNavigator is an abstract class. This abstract
> class has a couple subclasses already (MDINavigator
> and TabbedPaneNavigator), and more will be written in
> the future.
> We want to create unit tests (using JUnit, let's say
> AbstractUnitTest) which will apply to any
> AbstractNavigator. Herein lies the problem. I can't
> actually test the AbstractNavigator because I can't
> "have a(n)" AbstractNavigator since it's abstract.
> Therefore, I need to test a subclass of the
> AbstractNavigator, but currently, the only way I see
> of doing that (making the AbstractUnitTest "have a"
> MDINavigator) restricts the abstractedness of the unit
> tests. The AbstractUnitTest could not be used without
> recompiling, a step to be avoided.
> Another method we've thought of is to add a method
> "getNavigator" to the AbstractUnitTest which is called
> from the TestCase setUp() method. This getNavigator
> method would only be implemented by subclassing the
> AbstractUnitTest class and would then return the
> specific type of AbstractNavigator to be tested (i.e.
> MDINavigator). The problem with this solution is that
> the method of TestCase which returns the TestSuite is
> static and therefore cannot be overridden...where to
> go from here?
>
> If anyone can give us any more information about this
> kind of abstract unit testing, we would greatly
> appreciate it.
> Thanks,
> CJ
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
> Is it possible with JUnit 3.2 to order test methods, i.e. choose
> which test method to execute first ?
>
> For example :
>
> public class MyTest extends TestCase
> {
> [...]
> public void test2() {}
> public void test1() {}
>
> public static Test suite() {
> return new TestSuite(MyTest.class);
> }
> }
>
> I'd like to know for sure that test1() is called before test2().
afaik the following should work:
public static Test suite() {
TestSuite suite = new TestSuite("MyTest");
suite.addTest(new MyTest("test1"));
suite.addTest(new MyTest("test2"));
return suite;
}
Hope it helps,
Ilja
If you don't want to test your concrete classes, but only the they way your
abstract class behaves in a certain context, you could also create a
MockNavigator, that has a 'dummy' implementation for all the abstract
functions.
> -----Original Message-----
> From: Andreas Heilwagen [mailto:andreas.heilwagen@...]
> Sent: maandag 4 december 2000 23:12
> To: junit@egroups.com
> Subject: Re: [junit] JUnit Abstract Unit Testing
>
>
> Ok, here are my 5 cents:
>
>
> Why don't you ask a Factory to give you a list
> of navigator types. After that get the navigator instances
> from the factory one by one and test them.
>
> You can get the factory and the list of instances
> in a setUp() method. Write a test method for each kind
> of test and run it on all instances known to the
> factory.
>
> Thats the way I would try it,
>
> Andreas.
>
>
> >
> > I've been using JUnit to test my Java classes for a
> > few weeks now. I've reached a problem that others
> > have encountered as well.
> > Here's the problem:
> > I've been asked, by my team leader, to write what's
> > called an AbstractNavigator. It doesn't matter what a
> > Navigator is, the important point is that
> > AbstractNavigator is an abstract class. This abstract
> > class has a couple subclasses already (MDINavigator
> > and TabbedPaneNavigator), and more will be written in
> > the future.
> > We want to create unit tests (using JUnit, let's say
> > AbstractUnitTest) which will apply to any
> > AbstractNavigator. Herein lies the problem. I can't
> > actually test the AbstractNavigator because I can't
> > "have a(n)" AbstractNavigator since it's abstract.
> > Therefore, I need to test a subclass of the
> > AbstractNavigator, but currently, the only way I see
> > of doing that (making the AbstractUnitTest "have a"
> > MDINavigator) restricts the abstractedness of the unit
> > tests. The AbstractUnitTest could not be used without
> > recompiling, a step to be avoided.
> > Another method we've thought of is to add a method
> > "getNavigator" to the AbstractUnitTest which is called
> > from the TestCase setUp() method. This getNavigator
> > method would only be implemented by subclassing the
> > AbstractUnitTest class and would then return the
> > specific type of AbstractNavigator to be tested (i.e.
> > MDINavigator). The problem with this solution is that
> > the method of TestCase which returns the TestSuite is
> > static and therefore cannot be overridden...where to
> > go from here?
> >
> > If anyone can give us any more information about this
> > kind of abstract unit testing, we would greatly
> > appreciate it.
> > Thanks,
> > CJ
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Shopping - Thousands of Stores. Millions of Products.
> > http://shopping.yahoo.com/
> >
> >
> > To unsubscribe from this group, send an email to:
> > junit-unsubscribe@egroups.com
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>
>
>
I think you shouldn't rely on the order of the test methods.
From Martin Fowler's Refactoring-book (p98):
"It is important to run setUp and tearDown each time so that the tests are
isolated from each other. That means we can run them in any order and it
doesn't matter."
> -----Original Message-----
> From: Ilja Preu? [mailto:ilja.preuss@...]
> Sent: maandag 4 december 2000 23:14
> To: junit@egroups.com
> Subject: RE: [junit] Ordering of test methods ?
>
>
> > Is it possible with JUnit 3.2 to order test methods, i.e. choose
> > which test method to execute first ?
> >
> > For example :
> >
> > public class MyTest extends TestCase
> > {
> > [...]
> > public void test2() {}
> > public void test1() {}
> >
> > public static Test suite() {
> > return new TestSuite(MyTest.class);
> > }
> > }
> >
> > I'd like to know for sure that test1() is called before test2().
>
> afaik the following should work:
>
> public static Test suite() {
> TestSuite suite = new TestSuite("MyTest");
> suite.addTest(new MyTest("test1"));
> suite.addTest(new MyTest("test2"));
> return suite;
> }
>
>
> Hope it helps,
>
> Ilja
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>
>
>
I have finally got around to using JUnit for some of the development work I
do (all in Java). However, whilst JUnit is fine for testing "normal"
classes I'm really stuck on how to apply it to the application I'm building.
This application is agent-based and is therefore distributed,
multi-threaded, asynchronous and acts in response to incoming messages and
user interactions. It sits on top of an agent platform which makes it
slightly harder to form tests (you must start the platform before any tests
will work).
I understand that xUnit tests are normally focused on individual classes but
in my case the classes include the agent itself, several behaviours (i.e.
tasks), and utility classes. The utility classes are quite easy to test as
they are usually standard classes devoid of agent complications. The Agent
has very few methods of interest since it responds to messages placed in a
queue from either the GUI or other agents. Each behaviour maintains an
internal state which changes in response to messages and can be
characterised by either WAITING_FOR_USER, WAITING_FOR_MESSAGE,
PERFORMING_ACTION, or SENDING_MESSAGE. So my ideal tests would be to ensure
that the agent makes the correct state transitions in response to
valid/invalid messages and that it does this in each of the concurrent
behaviours.
Now that I actually write all this down it does seem kinda difficult!! But
I think many of the problems exist in systems like Jini, etc.
Given the large amount of distributed systems work involved in most
applications today I was hoping that someone would have typical patterns for
testing these systems. Any ideas?
Many thanks,
Jamie
There always seems to be one configuration or set of classes that takes
up the majority of the test bed work. When I am testing distributed classes
there are few additional things I do beyond the usual testing for regular
classes.
My basic testing regimen for most classes is:
(The original ideas for these are stolen from a book on testing Object
Oriented
Classes that I read so long ago I don't even remember who the author was.)
Functionality to be tested:
Constructors
Destructors
Accessors/Mutators AKA Properties
Common or Core Methods (things like persistence, assignment operators)
Key Methods (The reason we wrote the class in the first case...)
Types of tests to be conducted:
Tests for Basic Functionality
Tests for Boundary Functionality
Tests for Beyond Boundary Functionality
Tests for Destructive Functionality
When I am testing distributed applications I add the following:
Tests for Proof of Existence.
-----------------------------
Proof of existence demonstrates that a feature has been minimally
implemented.
With the possibility of mismatches between proxy code, idl, type libraries,
and remote servers it makes sense to test for the basic existence
of properties and methods. It provides a base test of the connection code as
well.
Other kinds of testing:
For the kind of event driven system you are talking about I would
typically produce an event generator that kicks out a series of events and
associated
data in an order than makes sense. It takes some work but it is well worth
it.
In addition I would use the event generator to do a specific type of testing
for
the kind of "protocol" you are talking about. It is called short tour
testing
and is excellent for pounding on a state retaining protocol (an FSM) so that
it correctly recovers from mis-sequenced communications and such.
The basic math for this comes from : "Design and Validation of Computer
Protocols"
by Holzmann. I first saw it in an article in C++ Journal or JOOPS about 5-6
years ago.
The basic theory is that for any complex sequence of events and data that
cause a
misbehaviour you can usually reproduce that problem using a short (~3-5
events) sequence.
The trick is to generate the sequence in a reproducible manner.
The solution is to take the number of events (or methods) to be executed and
assign an integer to each.
Then for each event assign an integer to each set of data (set of
parameters) that can be sent out.
Then the testing looks something like this:
int testNumber = 30000; // some large number
int numberOfEvents = 10; // As given by the protocol
int numberOfDataSetsPerEvent = 5; // As you desire..
int eventToBeSent;
while (testNumber != 0)
{
eventNdx = testNumber % numberOfEvents;
dataSetNdx = testNumber % numberOfDataSetsPerEvent;
// Send the event associated with eventNdx with the data associated with
dataSetNdx
// I often use the reflection API for this.
// Catch any exceptions thrown by the event execution and log them
// Log the target objects state (if applicable)
testNumber = testNumber - 1;
}
A very old example:
private void executeShortTour(int tour)
{
int methodNdx;
Method currMethod;
String currMethodName;
Vector currListOfParmLists;
Object[] currParmList;
int numberOfMethods = _Cfg.getMethodCount();
System.out.println("Starting Short Tour");
while ( tour != numberOfMethods )
{
methodNdx = tour % numberOfMethods;
currMethod = (Method) _Cfg.getMethod(methodNdx);
int numberOfParmLists = _Cfg.getParmListCount(currMethod);
int parmListNdx = tour % numberOfParmLists;
Object returnValue = null;
currParmList = (Object[])
_Cfg.getParmList(currMethod,parmListNdx);
if ( currParmList == null )
{
throw (new ProxyInitializationException(new String("Unable
to find parm list for method")));
}
System.out.println("Method(" + methodNdx + ") Parm Set(" +
parmListNdx + ") tour (" + tour + ")");
try
{
returnValue = currMethod.invoke(_Instance, currParmList);
invokationSuccessProlog(methodNdx, parmListNdx, returnValue,
currMethod, currParmList);
invokationSuccessEpilog(currMethod, currParmList);
}
catch(java.lang.reflect.InvocationTargetException
invocationTargetError)
{
invokationFailureProlog(methodNdx, parmListNdx, returnValue,
currMethod, currParmList, invocationTargetError.getTargetException());
invokationFailureEpilog(currMethod, currParmList,
invocationTargetError.getTargetException());
}
catch(java.lang.IllegalArgumentException illegalArgumentError)
{
invokationFailureProlog(methodNdx, parmListNdx, returnValue,
currMethod, currParmList, illegalArgumentError);
invokationFailureEpilog(currMethod, currParmList,
illegalArgumentError);
}
catch(java.lang.IllegalAccessException illegalAccessError)
{
throw (new ProxyInitializationException(new String("4")));
}
finally
{
}
tour--;
}
}
The point here is not to produce something that succeeds in every case. The
point is to execute this
test, check (via by eye review) that it succeeds when it should and fails
when it should, and use this
for regression and robustness checking.
The review can be a pain, but the effort is well worth it. You can also
create an Oracle class that
tells you what the expected behaviors should be and compares the actual
result to the predicted one.
How far you go depends on how much you want to pay for a given level of
robustness.
Thus ends my random exposition on how I tested my distribu apps this summer.
Have fun.
Jim JM
-----Original Message-----
From: Jamie Lawrence [mailto:hopeless@...]
Sent: Wednesday, December 06, 2000 2:27 PM
To: junit@egroups.com
Subject: [junit] xUnit testing of distributed systems
I have finally got around to using JUnit for some of the development work I
do (all in Java). However, whilst JUnit is fine for testing "normal"
classes I'm really stuck on how to apply it to the application I'm building.
This application is agent-based and is therefore distributed,
multi-threaded, asynchronous and acts in response to incoming messages and
user interactions. It sits on top of an agent platform which makes it
slightly harder to form tests (you must start the platform before any tests
will work).
I understand that xUnit tests are normally focused on individual classes but
in my case the classes include the agent itself, several behaviours (i.e.
tasks), and utility classes. The utility classes are quite easy to test as
they are usually standard classes devoid of agent complications. The Agent
has very few methods of interest since it responds to messages placed in a
queue from either the GUI or other agents. Each behaviour maintains an
internal state which changes in response to messages and can be
characterised by either WAITING_FOR_USER, WAITING_FOR_MESSAGE,
PERFORMING_ACTION, or SENDING_MESSAGE. So my ideal tests would be to ensure
that the agent makes the correct state transitions in response to
valid/invalid messages and that it does this in each of the concurrent
behaviours.
Now that I actually write all this down it does seem kinda difficult!! But
I think many of the problems exist in systems like Jini, etc.
Given the large amount of distributed systems work involved in most
applications today I was hoping that someone would have typical patterns for
testing these systems. Any ideas?
Many thanks,
Jamie
To unsubscribe from this group, send an email to:
junit-unsubscribe@egroups.com
I agree that each test should be independent (who am I to argue with
Martin Fowler?), but I still like to be able to order the tests. If a
small, supporting class has a problem, I'd rather find it early in the
tests and get a clear error message instead of finding a failure in a
more complex test because the supporting class failed.
So, I tend to use the static suite() method to order the tests. (Is it
documented anywhere that the tests will run in the order given within
suite()? I know they do at the moment, but I wonder if JUnit is
guaranteed to continue that way.) I run little tests first, and then
more complex tests that use features that have already passed.
Gerry
Vera Peeters wrote:
> I think you shouldn't rely on the order of the test methods.
>
> >From Martin Fowler's Refactoring-book (p98):
> "It is important to run setUp and tearDown each time so that the
> tests are
> isolated from each other. That means we can run them in any order
> and it
> doesn't matter."
>
>
> > -----Original Message-----
> > From: Ilja Preu? [mailto:ilja.preuss@...]
> > Sent: maandag 4 december 2000 23:14
> > To: junit@egroups.com
> > Subject: RE: [junit] Ordering of test methods ?
> >
> >
> > > Is it possible with JUnit 3.2 to order test methods, i.e. choose
>
> > > which test method to execute first ?
Hello,
This email message is a notification to let you know that
a file has been uploaded to the Files area of the junit
group.
File : /AllTests.java
Uploaded by : dxm@...
Description : AllTests to run all tests found in classpath
You can access this file at the URL
http://www.egroups.com/files/junit/AllTests%2Ejava
To learn more about eGroups file sharing, please visit
http://www.egroups.com/help/files.html
Regards,
dxm@...
There was a question on the JUnit egroup a while ago about automatically
running all test files.
I've just uploaded AllTests.java to the http://www.egroups.com/files/junit/.
This searches the classpath for class files, instantiates them, sees whether
they are tests, and if so adds them to a suite.
Run with your favourite testrunner, passing junit.contrib.AllTests as the
class name.
Anyone care to improve its test cases ;-?
Duncan Mc^Gregor
"The name rings a bell"
*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
**************************************************************************
I've just uploaded ZipAwareLoadingTestRunner.java to
http://www.egroups.com/files/junit/. This subclass of LoadingTestRunner is
able to load test classes which reference libraries which are in zip or jar
files. The library classes are not reloaded, but tests out of zips are.
Run as with LoadingTestRunner. You need it if you are getting
ClassNotFoundException's loading your test classes, but they and all your
required libraries are in the classpath.
I've searched my heart to find some economic way of testing the classes. If
you can think of a nice simple way please do let me know.
Duncan Mc^Gregor
"The name rings a bell"
*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
**************************************************************************
Anyone notice exceptions from tests only hold partial stack frames?
This makes debugging challenging unless you trap exceptions in your
tests making them cluttered.
This appears to be a side-effect of trapping
InvocationTargetException in TestCase.runTest(). At first sight, the
fillInStackTrace call seems to be the problem. I don't believe it's
desired in this case. It's removal, however, did not address the
problem. The target stack frame seems to be reset by the re-throw of
the target exception.
Commenting out the catch of InvocationTargetException fixes the
problem for me.
Thoughts?
Dan
What about enhancing InvocationTargetException so it holds a reference
to another exception. Then the catch could instantiate a new
exception, insert the reference to the caught exception, and throw the
new one. The contained exception should hold the stack information
about the original exception. This technique is used with JMSException
and seems to work well.
The only downside is that any code that catches the new exception must
check to see if there is a contained exception and decide what to do
with the information.
It would have been nice if there were an interface that described the
methods setLinkedException and getLinkedException (or whatever you
choose to call them) so code could have a general way to look for
contained exceptions.
Gerry
dsnider@... wrote:
>
> Anyone notice exceptions from tests only hold partial stack frames?
> This makes debugging challenging unless you trap exceptions in your
> tests making them cluttered.
>
> This appears to be a side-effect of trapping
> InvocationTargetException in TestCase.runTest(). At first sight, the
>
> fillInStackTrace call seems to be the problem. I don't believe it's
> desired in this case. It's removal, however, did not address the
> problem. The target stack frame seems to be reset by the re-throw of
>
> the target exception.
>
> Commenting out the catch of InvocationTargetException fixes the
> problem for me.
>
> Thoughts?
Send Email
