Myrna van Lunteren wrote:
On 2/2/06, *Andreas Korneliussen* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I think the work currently done on DERBY-874 was mainly to improve the
DerbyJUnitTest's JavaDoc, and to log exceptions. So I would not throw
that away.
However I do
So I guess what you are saying is that if the test framework provides a
common mechanism to give a Connection to a derby database, it should go
through a DataSource, instead of using DriverManager ?
I think we will need both mechanisms to get connection - using
DataSource and DriverManager.
Deepa Remesh wrote:
So I guess what you are saying is that if the test framework provides a
common mechanism to give a Connection to a derby database, it should go
through a DataSource, instead of using DriverManager ?
I think we will need both mechanisms to get connection - using
Deepa Remesh wrote:
So I guess what you are saying is that if the test framework provides a
common mechanism to give a Connection to a derby database, it should go
through a DataSource, instead of using DriverManager ?
I think we will need both mechanisms to get connection - using
DataSource
Myrna van Lunteren wrote:
On 1/31/06, *Kristian Waagan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Differences in output should be irrelevant. Although not what you
mentioned above, the issue of (execution) control is very relevant. The
logic for running the tests multiple
On 2/2/06, Andreas Korneliussen [EMAIL PROTECTED]
wrote:
I think the work currently done on DERBY-874 was mainly to improve theDerbyJUnitTest's JavaDoc, and to log exceptions. So I would not throw
that away.However I do propose to change DerbyJUnitTest to move out everythingabout configuration
On 1/31/06, Kristian Waagan [EMAIL PROTECTED] wrote:
Differences in output should be irrelevant. Although not what youmentioned above, the issue of (execution) control is very relevant. The
logic for running the tests multiple times, each time with a differentsetup/environment must be located
On 1/24/06, Kristian Waagan [EMAIL PROTECTED] wrote:
Kristian Waagan wrote:4) Should it be possible to run single JUnit test/suite from the
command line
2 yeahs snipped, 3rd: (Dan:)
I think it's essential that a single test can be run. I don't think it's essential that it is from test's main
Silly question(s):
with the Junit testsij is not used?
if not, and we're going to convert all tests to junit, should there be a new test to test the tool ij specifically (at some point) ?
Myrna
Hi Myrna,
I don't think we've discussed yet how or when we would convert existing
tests to JUnit. I agree that ij needs to continue to be tested.
Regards,
-Rick
Myrna van Lunteren wrote:
Silly question(s):
with the Junit tests ij is not used?
if not, and we're going to convert all tests to
Myrna van Lunteren wrote:
On 1/24/06, *Kristian Waagan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Kristian Waagan wrote:
4) Should it be possible to run single JUnit test/suite from the
command line
2 yeahs snipped, 3rd: (Dan:)
I think it's essential that a single test
Rick Hillegas wrote:
Kristian Waagan wrote:
2) Should we support setting up a shared test fixture for a set of
tests?
This is a common issue with JUnit, and there are mechanisms to handle
it. For instance, we could let tests that require this to wrap itself
in a TestSetup instance (as
I think there's a lot of value in having a suite-level setup mechanism,
I totally agree that doing setup for each test can be overkill and I am
often finding ways to work around it.
David
Kristian Waagan wrote:
Rick Hillegas wrote:
Kristian Waagan wrote:
2) Should we support setting
Thanks, Kristian. This is indeed helpful. My takeaway is that our JUnit
primer should recommend something like this as the pattern if developers
need to move the setup()/teardown() brackets outside a cluster of tests.
Regards,
-Rick
Kristian Waagan wrote:
Rick Hillegas wrote:
Kristian
Daniel John Debrunner wrote (2006-01-24 20:23:27):
The other issue is that we have a great opportunity to start out with
JUnit tests that follow a consistent pattern and provide a great example
for others to follow.
+1
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer,
I have to agree we're missing a well-defined pattern and associated
guidebook on how to do this right. And I agree we should get this
done before too many more JUnit tests are written.
David
Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I
I apologize for the radio silence on this topic. I have been on the road
and unable to address these concerns. Today I will put some effort into
beefing up the comments in DerbyJUnitTest and handling the swallowed
exceptions.
I agree that we need a primer for writing JUnit tests. I can mock
Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I agree with you that is disconcerting, but can't JUnit tests be written
that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest
cleaned up to everyone's satisfaction?
Depends,
One thing that would be great is if there was a well defined way to
have tests handle jvm specific, framework specific or version specific
logic, since there will have to be some replacement for the many
properties in the test harness and the individual test checks for
framework that we have
Hi Deepa,
Thanks for bringing this up. I agree that being able to run JUnit tests
on the small device configuration would be a good idea.
Regards,
-Rick
Deepa Remesh wrote:
One thing that would be great is if there was a well defined way to
have tests handle jvm specific, framework
David W. Van Couvering wrote:
Kristian Waagan wrote:
4) Should it be possible to run single JUnit test/suite from the
command line by simply invoking the main method?
Personally, I think this should be possible. This require us to remove
the current use of main for running a test in the
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
Kristian Waagan wrote:
4) Should it be possible to run single JUnit test/suite from the
command line by simply invoking the main method?
Personally, I think this should be possible. This require us to remove
the current use of
David W. Van Couvering wrote:
Hi, Kristian, thanks for your questions. My one overriding thought is
we should take this in incremental steps -- do all of these questions
need to be answered before we can rewrite a single old canon-based test
to a JUnit test? Can some of these questions be
On 1/24/06, Kristian Waagan [EMAIL PROTECTED] wrote:
David W. Van Couvering wrote: Hi, Kristian, thanks for your questions.My one overriding thought is we should take this in incremental steps -- do all of these questions need to be answered before we can rewrite a single old canon-based test
to
Francois Orsini wrote:
On 1/24/06, *Kristian Waagan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
David W. Van Couvering wrote:
Hi, Kristian, thanks for your questions. My one overriding thought is
we should take this in incremental steps -- do all of these
I agree with you that is disconcerting, but can't JUnit tests be written
that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest
cleaned up to everyone's satisfaction?
BTW, if you don't like the rampant catching and ignoring, is anything
preventing you from going in and fixing it?
David W. Van Couvering wrote:
I agree with you that is disconcerting, but can't JUnit tests be written
that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest
cleaned up to everyone's satisfaction?
Depends, at some point you put the potential burden of fixing all those
new tests on
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I agree with you that is disconcerting, but can't JUnit tests be written
that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest
cleaned up to everyone's satisfaction?
Depends, at some point you put the potential
28 matches
Mail list logo
