Hi,
It has been written, by the majority, I believe, and perhaps by everyone,
that no
testing software of any kind should be delivered with the
project we submit to Sun.
While I have not yet decided whether I will submit self-verifying software,
and if I do, to what extent (unit tests, sub-system tests, overall system
tests), I am certainly considering this option, and I now submit my reasoning
which, upon reading, you may have a contrary opinion to post so that I may
reconsider my stance.
In the real world, you often have a software company sell an application and
then say to the user: you must use Sun's JRE version 1.2 until at some future
time we have verified that our software works under a later version.
On Mac OS X, this is not much of a problem, because it comes with many prior
versions, so the user can run one application under JRE 1.2, and simultaneously
run a different application under JRE 1.4. However, I suspect that the majority
of computer users don't have such a flexible set-up, and so they only have one
JRE version available on their computer; this places them in a hard place: they
want their old software to function, but it has not been verified to work in the
latest JRE, and they simultaneously want to purchase new software which only
works in the latest JRE.
If, then, the company which originally sold the software, shipped the software with
self-verification code, the client could, with some degree of assurance, run these
tests and then upgrade their JRE, even if the original company went out of business.
You see similar efforts made in
JUnit, which comes with a JUnit test which tests that
JUnit is operating correctly.
Concerning the Sun exam project, have self-verifying tests obviously is not a requirement;
but, since I am creating them for the most important part of the project (Data and DBMain),
it would not take much extra effort to embed the JUnit tests into the application itself;
the user would simply go to the preferences panel, and given the appropriate conditions
(such as ensuring that the mode is local, and that a test, junk database is being used),
the self-verifying JUnit tests can be fired off (though this assumes that the project is
delivered with JUnit, which, in and of itself, may not be allowed; however, if JUnit is
not present, the application can simply say that the self-verification tests cannot proceed
until JUnit is made available to the application).
In short, assuming that I don't deliver JUnit with my software, I don't see any drawbacks
to there being the option to allow the user to let the software verify (to some degree)
that it functions on the given JRE and on the given operating system.
And, in the real world, disregarding the exam, given that the underpinning, the JRE, is
contantly changing, I would think that a self-verifying application is a very good idea.
Your ideas?
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]