[BUG] Re: FileDirectory>>exists

Anthony Adachi adachipro at yahoo.com
Tue May 20 19:00:11 UTC 2003


--- In squeak at yahoogroups.com, Lukas Renggli
<renggli at h...> wrote:

>  I just discovered that the message
FileDirectory>>exists is returning
>  true, even when the receiver is a file and not a
directory. I am
>  currently working with a 3.5-5180 image on Mac OS
X. 

Perhaps, we should start illustrating bugs and
expected behaviour as test cases in order to make it
more clear as to what the correct results should be? 

>I just discovered that FileDirectory>>exists does not
return the values I expect

For instance, is this what you mean to say and what
you expect?

FileDirectoryTests >>testAttemptCreateInstanceWithFile
"Should we be able to create a FileDirectory instance
with a file?"
| directory |
FileDirectory default
				forceNewFileNamed: 'aTestFile'.
directory _FileDirectory default
				directoryNamed: 'aTestFile'.
self shouldnt: [directory exists]
	description: 'Files are not directories.'.
	
	>  	The tests
>  	FileDirectoryTests>>testDirectoryExists,
>>testExists and
>  	>>testDeleteDirectory do also fail in that
configuration. It seem to
>  	work with Windows, so I think this is a platform
related problem.

I can confirm that those tests fail on Mac OS 9.1.

Upon running sUnit I checked to see which assertions
failed. I traced the problem in all three failing
tests down to the final assertion in this test:

FileDirectoryTests >> testDeleteDirectory
	"Test deletion of a directory"
	
	self assert: self myAssuredDirectory exists.
	self myDirectory containingDirectory deleteDirectory:
self myLocalDirectoryName.
	self shouldnt: [self myDirectory exists] "<- this
assertion fails!"
	
FileDirectoryTests >> testDeleteDirectory
	"Test deletion of a directory"
	
	self assert: self myAssuredDirectory exists.
	self myDirectory containingDirectory deleteDirectory:
self myLocalDirectoryName.
	self shouldnt: [self myDirectory exists]"<- this
assertion fails!"
	
The interesting thing about the above test is that the
test folder created by the 'myAssuredDirectory'
message , 'zTestDir', does indeed get deleted.

The existence tests fail because they call upon the
testDeleteDirectory test. This leads to misleading
results as far as what their intent is concerned. In
other words, they don't appear to have been isolated
enough.

I confirmed this by creating an more isolated
existence test. This test passed:

FileDirectoryTests>>testNonExistentDirectory

	| directory parentDirectory |
	directory _FileDirectory default
				directoryNamed: 'nonExistentFolder'.
	self shouldnt: [directory exists] 
		description: 'A FileDirectory instance should know
if it points to a non-existent directory.'.

	parentDirectory _FileDirectory default.
	self shouldnt: [parentDirectory directoryExists:
'nonExistentFolder'] 
		description: 'A FileDirectory instance should know
when a directory of the given name doesn''t exist'.

By the way, Lukas, can you confirm that the above test
passes on Mac OS X? 

So, the 'testNonExistentDirectory' test passed but the
last assertion in 'testDeleteDirectory' which uses the
'exists' message failed (even though the test folder's
creation and deletion was indeed successful in the
Finder). What does this mean? What exactly is broken?

On a side note: It would be most helpful if would
could document our concerns with broken tests to
isolate and prove that a bug exists or to prove
desired alternate behaviour. If we illustrate the
behaviour one expects or desires with unit tests not
only does it make it concrete what one expects (in a
form that can be proved) it would make it easier for
those responsible for to correct the issue if unwanted
behaviour does indeed exist. 

If those listening deem that one's test makes the
wrong assumptions or one has the wrong expectations on
how to use a class then they could respond by
illustrating their point with tests which illustrate
correct usage and which make the correct assumptions.

Moreover, in cases where there's a "missing" feature
which one would like to have implemented in Squeak it
would make it easier for those concerned to create it
if they first had a broken unit test. A broken test
which concretely shows what one desires and which will
pass when the feature is implemented.

Just a thought,

Anthony

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



More information about the Squeak-dev mailing list