Perfect. The Java IO classes are pretty damend flexible.,
Jim
-----Original Message-----
From: Blum, Robert [mailto:rblum@...]
Sent: Tuesday, November 28, 2000 1:04 PM
To: 'junit@egroups.com'
Subject: RE: [junit] Test File Output comparison : Should probably be an
F AQ but I didn't see it so....
> I am not sure that I grok what you are saying.
UhOh. I didn't have my coffee yet :-)
> As a concrete example I am currently working on a a templated
> code generator implemented as a Javadoc DocLet. So I run Javadoc
>, giving it the classname of the doclet and the name
> of the code template, and the doclet takes the supplied class
> information from Javadoc and produces an output file according to the
> template's instructions. It is a simple program, using the reflection
> API and the doclet API to do most of the work.
Not having an idea about doclets, I don't know if the following is
applicable
> Most of the 9 classes can be quickly and cleanly unit tested
> with little work. But the overall transformation from Template
> to generated code also needs to be unit testable for refactoring
> and maintainence reasons.
For simplicity, let's assume that work is done in a class called
Transformer...
> As far as I can tell, I need a standard "oracular" or dummy doclet
> information provider to act as the source of class information and
> a standard template to test as well as
> a piece of transformed output to verify against.
> The template and canonical output could be embedded as strings in the
> program itself.
> But the transformed text (going out via a PrintWriter class)
> I believe is only accessible as a file.
So, basically, you have something like
Transformer.DoTransform(DocletInfoProvider info,String template,PrintWriter
out)
Ignore the first two parameters... the PrintWriter is the important part
> Am I wrong ? Can I restructure this so that it is
> unit testable writing to and from buffers and still manageable
> as a file output type of tool ?
If you pass the PrintWriter in, this is directly unit testable.
Set up a PrintWriter like this:
// ... set up Doclet info provider and template
// set up print writer
ByteArrayOutputStream stream = new ByteArrayOutputStream; //
Get an output stream to hold the results
PrintWriter out=new PrintWriter(stream); // all
output ends up in stream
// call your method
Transformer.DoTransform(info,template,out);
// Now, stream should contain the expected result
assertEquals(expectedOutputString,stream.toString());
That should do the trick...
> >One of the benefits you reap if you implement your classes
> that way is that
> >you can add MD5 checksums, compression, etc without any
> redesign. If your
> >class is writing directly to a file, you would have to
> modify that class to
> >achieve the same.
>
> >Of course, that's only a guess - I could be completely off :-)
>
> I think it is clear from my question above that I lack an
> understanding of
> how
> this would be achieved within the Javba I/O library.
Compression and checksums? Checksums are implemented by CheckedOutputStream.
Compression is a ZipOutputStream. They all inherit from FilterOutputStream.
>
> Awaiting your response with baited breath
Hopefully I could answer your question. If that's not what you were looking
for, I'm probably misunderstanding your problem.
Bye,
Robert
Please be aware that messages sent over the Internet may not be secure and
should not be seen as forming a legally binding contract unless otherwise
stated. Furthermore, I am not speaking for Midway Games in any way - this is
a strictly personal message.
To unsubscribe from this group, send an email to:
junit-unsubscribe@egroups.com
> If you pass the PrintWriter in, this is directly unit testable.
>
> Set up a PrintWriter like this:
>
> // ... set up Doclet info provider and template
>
> // set up print writer
> ByteArrayOutputStream stream = new
> ByteArrayOutputStream; //
> Get an output stream to hold the results
> PrintWriter out=new PrintWriter(stream); // all
> output ends up in stream
>
> // call your method
> Transformer.DoTransform(info,template,out);
>
> // Now, stream should contain the expected result
> assertEquals(expectedOutputString,stream.toString());
I think, a StringWriter would be more appropriate...?
ciao, Ilja
> I think, a StringWriter would be more appropriate...?
Well, depends. If his functions are expecting a PrintWriter, what can you
do...
If they're expecting a Writer, you can feed a StringWriter.
Bye,
Robert
Disclaimer:
Please be aware that messages sent over the Internet may not be secure and
should not be seen as forming a legally binding contract unless otherwise
stated. Furthermore, I am not speaking for Midway Games in any way - this is
a strictly personal message.
I think JUnit* should be kept light, perhaps with plug-ins. If you
include all nice-to-have options a lot of people won't like it any
more because it gets complicated.
Jim Jackl-Mochel wrote:
>
> Thanks Erik,
> I am suprised that this (and equivalent tests for binary files) hasn't
> become
> a part of one of the base classes. Does anyone know why (time, philosophy,
> etc ) ?
>
> One of the most common situations for me in testing tools is the need to
> test a given file output against a canonical output file.
>
> Thanks again,
> Jim JM
>
> -----Original Message-----
> From: Erik [mailto:emeade@...]
> Sent: Monday, November 27, 2000 7:51 PM
> To: junit@egroups.com
> Subject: RE: [junit] Test File Output comparison : Should probably be an
> FAQ but I didn't see it so....
>
> > -----Original Message-----
> > From: Jim Jackl-Mochel [mailto:jmochel@...]
> > Sent: Monday, November 27, 2000 11:18 AM
> > To: JUnit List
> > Subject: [junit] Test File Output comparison : Should probably be an FAQ
> > but I didn't see it so....
> >
> >
> > I was wondering if anyone has coded up an test case base class that allows
> > for file comparisons of output files ? I expect that it would
> > look something
> > like assertFilesEqual(file1, file2)
> >
> > Thanks,
> > Jim JM
> >
>
> I don't have one coded up in a base class, but here is the code I use...
>
> public void assertFilesEqual(File fileOne, File fileTwo) {
> assertEquals(readFile(fileOne), readFile(fileTwo));
> }
>
> private static String readFile(File fileToRead) {
> StringBuffer fileContents = new StringBuffer("");
> try {
> BufferedReader in = new BufferedReader(new
FileReader(fileToRead));
> String line;
> while ((line = in.readLine()) != null) {
> fileContents.append(line+"\n");
> }
> in.close();
> } catch (Exception e) {
> System.err.println(e.toString());
> return "";
> }
> return new String (fileContents);
> }
>
> 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, a StringWriter would be more appropriate...?
>
> Well, depends. If his functions are expecting a PrintWriter,
> what can you
> do...
>
> If they're expecting a Writer, you can feed a StringWriter.
Well, I was talking about replacing the *ByteArrayOutputStream* by a
StringWriter. You can wrap the StringWriter in a PrintWriter the same
way as the Stream.
ciao, Ilja
> -----Original Message-----
>
> Well, I was talking about replacing the *ByteArrayOutputStream* by a
> StringWriter. You can wrap the StringWriter in a PrintWriter the same
> way as the Stream.
>
Aah - I see. Most of our classes uses Streams, so I was stuck in the 'need a
stream' mindset :-)
But is there any benefit of using a StringWriter instead?
Disclaimer:
Please be aware that messages sent over the Internet may not be secure and
should not be seen as forming a legally binding contract unless otherwise
stated. Furthermore, I am not speaking for Midway Games in any way - this is
a strictly personal message.
Light is always such a subjective term. Just think of all those
"thin-clients" out that that require a browser weighing in
at about 17 meg in memory :-)
I would say I lean more to the "it should be simple enough to do the job but
no simpler" world view.
My dividing line on that hovers around 50%. If it turns out that 50% the
typical users
have coded up some equivalent set of file comparison code sometime in their
life than
it should probably be included. Of course, it doesn't have to be included as
part of the TestCase class
it could be in a subclass like StreamOutputTestCase, etc.
Of course, now that I know what's going on, I will probably code up some
equivalent and
try submitting it to the Junit maintainers
Thanks,
Jim JM
-----Original Message-----
From: Andreas Heilwagen [mailto:andreas.heilwagen@...]
Sent: Tuesday, November 28, 2000 5:07 PM
To: junit@egroups.com
Subject: Re: [junit] Test File Output comparison : Should probably be an
FAQ but I didn't see it so....
I think JUnit* should be kept light, perhaps with plug-ins. If you
include all nice-to-have options a lot of people won't like it any
more because it gets complicated.
Jim Jackl-Mochel wrote:
>
> Thanks Erik,
> I am suprised that this (and equivalent tests for binary files)
hasn't
> become
> a part of one of the base classes. Does anyone know why (time, philosophy,
> etc ) ?
>
> One of the most common situations for me in testing tools is the need to
> test a given file output against a canonical output file.
>
> Thanks again,
> Jim JM
>
> -----Original Message-----
> From: Erik [mailto:emeade@...]
> Sent: Monday, November 27, 2000 7:51 PM
> To: junit@egroups.com
> Subject: RE: [junit] Test File Output comparison : Should probably be an
> FAQ but I didn't see it so....
>
> > -----Original Message-----
> > From: Jim Jackl-Mochel [mailto:jmochel@...]
> > Sent: Monday, November 27, 2000 11:18 AM
> > To: JUnit List
> > Subject: [junit] Test File Output comparison : Should probably be an FAQ
> > but I didn't see it so....
> >
> >
> > I was wondering if anyone has coded up an test case base class that
allows
> > for file comparisons of output files ? I expect that it would
> > look something
> > like assertFilesEqual(file1, file2)
> >
> > Thanks,
> > Jim JM
> >
>
> I don't have one coded up in a base class, but here is the code I use...
>
> public void assertFilesEqual(File fileOne, File fileTwo) {
> assertEquals(readFile(fileOne), readFile(fileTwo));
> }
>
> private static String readFile(File fileToRead) {
> StringBuffer fileContents = new StringBuffer("");
> try {
> BufferedReader in = new BufferedReader(new
FileReader(fileToRead));
> String line;
> while ((line = in.readLine()) != null) {
> fileContents.append(line+"\n");
> }
> in.close();
> } catch (Exception e) {
> System.err.println(e.toString());
> return "";
> }
> return new String (fileContents);
> }
>
> 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
To unsubscribe from this group, send an email to:
junit-unsubscribe@egroups.com
Hi all,
I was wondering if anyone has successfully gotten junit to work with
Mandrake7.2. I have been using junit on NT for a while now. I have been
experimenting with moving all our java components to build on a linux box
but have not had much success in even launching junit. Any suggestions?
Thanks,
Dan
Dan MacKay wrote:
>
> Hi all,
>
> I was wondering if anyone has successfully gotten junit to work with
> Mandrake7.2. I have been using junit on NT for a while now. I have been
> experimenting with moving all our java components to build on a linux box
> but have not had much success in even launching junit. Any suggestions?
Not on Mandrake, but on Linux. Works fine. Can you define "not had
much success" with a little more detail?
>
> Thanks,
> Dan
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@...
Try JUnitX on http://www.extreme-java.de. It is an extended version
which
can be build using ant. So you only need a JDK installed (Sun JDK 1.3
final
preferred) to build it. You can even selftest JUnitX from the included
ant control files.
That might help if you want to try building JUnit another way.
Regards,
Andreas.
Dan MacKay wrote:
>
> Hi all,
>
> I was wondering if anyone has successfully gotten junit to work with
> Mandrake7.2. I have been using junit on NT for a while now. I have been
> experimenting with moving all our java components to build on a linux box
> but have not had much success in even launching junit. Any suggestions?
>
> Thanks,
> Dan
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
Hi David,
I keep on getting thread violations when I run test suites. I am going to
try Andreas suggestion and will let you know how it goes.
Thanks,
Dan
> -----Original Message-----
> From: dcorbin@... [mailto:dcorbin@...]On Behalf Of David
> Corbin
> Sent: Thursday, November 30, 2000 11:45 AM
> To: junit@egroups.com
> Subject: Re: [junit] junit and Linux (Mandrake7.2)
>
>
> Dan MacKay wrote:
> >
> > Hi all,
> >
> > I was wondering if anyone has successfully gotten junit to work with
> > Mandrake7.2. I have been using junit on NT for a while now. I have been
> > experimenting with moving all our java components to build on a
> linux box
> > but have not had much success in even launching junit. Any suggestions?
>
> Not on Mandrake, but on Linux. Works fine. Can you define "not had
> much success" with a little more detail?
>
> >
> > Thanks,
> > Dan
> >
> >
> > To unsubscribe from this group, send an email to:
> > junit-unsubscribe@egroups.com
>
> --
> David Corbin
> Mach Turtle Technologies, Inc.
> http://www.machturtle.com
> dcorbin@...
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@egroups.com
>
>
>
Hi Adreas,
Thanks for the tip. I'll give it a go.
Dan
> -----Original Message-----
> From: Andreas Heilwagen [mailto:andreas.heilwagen@...]
> Sent: Thursday, November 30, 2000 1:21 PM
> To: junit@egroups.com
> Subject: Re: [junit] junit and Linux (Mandrake7.2)
>
>
> Try JUnitX on http://www.extreme-java.de. It is an extended version
> which
> can be build using ant. So you only need a JDK installed (Sun JDK 1.3
> final
> preferred) to build it. You can even selftest JUnitX from the included
> ant control files.
>
> That might help if you want to try building JUnit another way.
>
> Regards,
>
> Andreas.
>
>
> Dan MacKay wrote:
> >
> > Hi all,
> >
> > I was wondering if anyone has successfully gotten junit to work with
> > Mandrake7.2. I have been using junit on NT for a while now. I have been
> > experimenting with moving all our java components to build on a
> linux box
> > but have not had much success in even launching junit. Any suggestions?
> >
> > Thanks,
> > Dan
> >
> >
> > 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
>
>
>
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 ?
Jim JM
>
> 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'm using Hypersonic SQL. It's a small JDBC driver that allows you to have
in-memory database. Just setup your tables at test construction time, and
you're ready to rock'n'roll
Bye,
Robert
Disclaimer:
Please be aware that messages sent over the Internet may not be secure and
should not be seen as forming a legally binding contract unless otherwise
stated. Furthermore, I am not speaking for Midway Games in any way - this is
a strictly personal message.
> 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/
Send Email
