2003-09-19  Toby H Ferguson  <toby.h.ferguson@sun.com>

	* CommandLineParserTest.java
	(testSimpleConstruction): the error message here is insufficient -
	it should say that teh command was a null!

2003-09-17  Toby H Ferguson  <toby.h.ferguson@sun.com>

	* OutputTest.java (testSimpleUse): print()'ing an object causes the
	underlying string to have a newline appended. This is surely not
	what is intended!

2003-09-16  Toby H Ferguson  <toby.h.ferguson@sun.com>

	* UserInputTest.java (testEncoding): Setting the encoding of a
	UserInput causes an error because the original stream was
	closed. This doesn't work!

	* LocalStringsManagerTest.java (testReplacementException): The
	exception isn't very informative. This could be a much clearer
	message for the user, listing the format string obtained, the
	replacement args. etc. etc.

	* CommandFactoryTest.java: There's confusion over the use of
	interfaces, abstract classes and factories. The Command class is a
	(base class) implementation of the ICommand interface. As much as
	possible everything (especially clients) should use the ICommand
	interface, not the Command class. Internally, too, the ICommand
	interface is preferable, since it permits a change in
	implementation. I think that the ICommand interface has been
	somewhat ignored - the Command base class has many more public
	methods than are in ICommand, and yet ICommand would be the
	appropriate place for them to be recorded!
	(createCommand): The CommandFactory could be refactored to
	reduce coupling - the createCommand method is coupled to the
	LocalStringsManagerFactory. This could be separated into two
	methods - one of which would throw an exception indicating the
	problem, (null argument, class creation exception), the other
	would translate these exceptions into a
	CommandValidationException.
	(testNullClass): This class really relies upon
	ValidCommand containing a non-null className - it would seem
	better to construct ValidCommands that gaurantee this property. As
	it is, the error message doesn't actually indicate what the
	problem is, but gives a vague statement which can only be tracked
	down by looking at the source code! The error being caught here
	could've (and should've) been caught earlier, and reported in a
	context where the user could do something about it. In addition,
	this factory method probably isn't the best pattern for building a
	set of commands from an XML file - a better pattern would be the
	Builder pattern. But this is an architectural change.
	(testInvalidClass): The error message doesn't give sufficient
	information to determine what went wrong - it might do in the log,
	but I don't know that. The error message should at least state
	that the class (name it!) could not be found. (I think it would
	make sense to give the classpath here too - but that might be a
	security hole). 

2003-09-15  Toby H Ferguson  <toby.h.ferguson@sun.com>

	* UserInputTest.java (testEncodingProblem): The comment for setEncoding
	should state the encoding string is the name of a
	java.nio.charset.Charset. The exception thrown should be a
	java.io.UnsupportedEncodingException since this is an exception
	that can be handled by the caller.
	(testEncodingProblem): The error message returned is not very useful,
	unless the user is told that it was an UnsupportedEncodingException.
	(testEncoding): The abstraction is incomplete - setEncoding should
	have a getEncoding observer, so that the underlying encoding can
	be discovered.

	* ValidOptionTest.java (testRequired): the pair isValueRequired()
	and setRequired() are poorly named. Either both should be
	ValueRequired, or Required.
	(testRequired): isValueRequired() should return a boolean, not the
	int that it does return.

	* ValidCommandTest.java: ValidCommand uses a Vector as its
	internal representation of options. However it does not appear
	that the order of options is important and that the code attempts
	to gaurantee uniqueness. It would appear that using a HashSet
	would be a better way of implementing the class, enabling some
	code to be removed, and remaining code to be simplified.
	(testToStringNonEmpty): There's a bug here - line 353 - a vector
	is being appended to a string. I've commented out the offending
	line in the test.

	* LocalStringsManagerFactoryTest.java: LocalStringsManagerFactory
	has a static initializer
	LocalStringsManagerFactory.getClass().getPackage().getName(). However
	getPackage() can return a null, so this is a null pointer
	exception waiting to happen! It is triggered using the dynamic
	coverage invocation of JCov.

2003-09-13  Toby H Ferguson  <toby.h.ferguson@sun.com>

	* ValidCommandTest.java (testValidOptionsNullCase): getOption needs to be
	able to handle a ValidOption that was constructed using the
	default constructor (i.e. getName() returns null). Commenting out
	this test case.
	(ValidCommandTest): Is it an error to add two options whose names
	are the same but otherwise different? ValidCommand seems to treat
	name equality as object equality, yet that function should
	therefore by on ValidOption, not in ValidCommand.
	(testHasValidObjectNullName): Another problem handling
	ValidOptions constructed using the empty constructor. Commented
	this test out.

2003-09-12  Toby H Ferguson  <toby.h.ferguson@sun.com>

	* ValidCommandTest.java (testBasicConstruction): ValidCommand
	contains a potential bug - references to its collections
	(validOptins, RequireOptions, Properties) are all given to a
	client, although the variables themselves are private. This would
	allow a client to change the contents. The abstraction provided is
	rather thin - no more than a veneer on a collection of collections.
	(testValidOptionsWithAString): Bug - ValidCommand will only accept a vector
	of ValidOption, but doesn't check for this, thus causing a
	ClassCastException. Commenting out this test case.

	* ValidPropertyTest.java (testValueMutation): vp.setValue() has a
	bug. Commenting out this test case.

