• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: Self-Verifying Project Submittal

 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic