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 can be run. I don't think
it's
>> essential that it is from test's main method. The harness produces the
>> useful functionality of setting up the correct environment for the
test,
>> not sure if that could be duplicated in evey main method for every
test.
>Good point Dan.
>Citing Dan: "...harness produces the useful functionality of setting up
>the correct environment for the test,...".
>Can somebody please explain to me what is actually done by the harness?
>I did have a quick look at the harness code, but I would need to study
>it a bit more to understand what it actually does. Stating what the
>harness does when it comes to setting up the environment for tests would
>be good for the general understanding of the test execution process.
---------------
I've had this messages 'starred' in gmail for a bit, sorry for
replying only now. There's no quick way to describe what the
'functiontest' harness does - I've tried to describe what I understand
in the past (see the java/testing/README.htm)...
Maybe if you have specific questions I'll be able to answer better.
The main thing I think that the functiontest harness does is set up
all sorts of fun properties for the tests to use, so the same test can
run in a number of different ways - in a suite, by itself, with
different encryption algorithms, with encoding, locales, frameworks,
with java.sql.DriverManager or instead with DataSource; to run in
sequence or separately, start a new database or not...Depending on
these properties, more or less 'magic' is done - for example, network
server gets started or not, files needed for the test get copied
around...
Properties in a suite override properties set for individual tests
lower level.
Also, it is able to figure out what jvm is used and add specific
(non-standard) properties as needed or applicable.
A big part of it is to control, and eliminate uninteresting
differences in the output, but that would be irrelevant with Junit, yes?
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 times, each time with a different
setup/environment must be located somewhere. I think Andreas' proposal
of introducing a separate JUnit test type (see
http://www.nabble.com/running-JUnit-tests-t887682.html#a2300670) makes
sense, as it gives us more freedom w.r.t. handling of JUnit tests.
Does this help at all?
But maybe that wasn't what Dan meant?
Myrna
Thanks for the answer Myrna. And good work on the readme! I just skimmed
through it now, but I will take the time to read it thoroughly soon.
Right now I feel that it is very hard to start writing a new JUnit
harness, since the old harness seem to contain a lot of functionality
and "magic". I wonder if it would be best to just start
converting/writing some tests and create a framework along the way.
The above approach would probably result in several major rewritings of
"the new framework" and the existing JUnit tests, but it might be better
than thinking out everything at once (that's hard!). Perhaps I will
rewrite an old test I have been working a little on, and put it out for
review and comments, unless someone else beats me to it ;)
--
Kristian
