[BUG] Re: FileDirectory>>exists

Stephane Ducasse ducasse at iam.unibe.ch
Tue May 20 19:25:54 UTC 2003


Hi anthony

You are right, having tests is important and much more readable. Lukas 
knows that because
SmallWiki is full of tests :).
Could you send your tests as changeset plus put [TEST] (marcus is it 
correct?) so that marcus
collect them?

Thanks

Every small step is a step in the right direction :)

On Tuesday, May 20, 2003, at 09:00 PM, Anthony Adachi wrote:

> --- 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