[BUG] FileDirectory>>exists

Anthony Adachi adachipro at yahoo.com
Wed May 21 16:35:57 UTC 2003


Lukas Renggli wrote:

>In my personal opinion it is quite painful to work
with FileDirectory.
>Especially when working with specific files, you
always have to remember
>two things: the FileDirectory and the String with the
filename. It would be
>great to have a more sophisticated (and oo) way of
working with files. My
>idea would be to have a new class called Filename
that represent files
>only. As a result, we would be able to move a lot of
stuff from
>FileDirectory to Filename. Like this - I think - we
get rid of that kind of
>problems. Some examples could be:
>
>FileDirectory>>newFileNamed: localFileName
>Filename>>writeStream
>
>FileDirectory>>copyFileNamed: fileName1 toFileNamed:
fileName2
>
>Filename>>copyToDirectory: aFileDirectory
>Tell me what do you think about this. I would be
eventually able to come up with a more detailed
proposal.

Lukas, could you please write this up as a unit test?
As I'm not clear on what you're saying. An explanation
unit test would make it easier to understand what
interface you desire and the behaviour you expect as a
result of sending messages to it. 

Also, as a result of witting a broken test it might
give those responsible for Squeak's file handling more
motivation to make the change you suggest and would
make it easier for them to make it work.

By the way, are you familiar with test first coding or
Test Driven Development? In test first coding one
starts off with a broken test. i.e.- One writes a test
before the implementation is written. Even if you're
not the one who is going to eventually make that test
pass. Then, one writes the implementation code until
the test runs without errors or failures. As Ron
Jefferies says:

“You just write code as if someone has already written
the hard method for you and you just have to send the
message”

For instance, you might start off by pondering: 

"Let's see, what do I wish to do? I would like to have
a class like Filename (and I have decided to call it
that name because I think it expresses the intentions
I desire for it quite well)."

Then you might go on to write a test class named,
'FilenameTest' (sub class of TestCase).

Next, you might desire: "I would like to copy a file
and the results to be thus: I would like to have
copied a file to another directory". You could express
this by first witting the assertion:

FilenameTest>>testCopyingToAnotherDirectory
"My idea is to have a new class called Filename that
represent files only."
| actualResult |
self should: [actualResult = 'code your expected
result. i.e.-file exists in directory']
	description: 'Should copy a file to the indicated
directory'.

Note, that we don't worry about how the file is going
to get copied or even how to create a  Filename class.
We may not be even sure of the message we would like
to send to make it happen yet. 

Then you might ponder: "What's the message I would
like to send to make this happen. What's the easiest
and simplest method I wish I had. I would like to be
able to send it a copyToDirectory: aFileDirectory
message. I think this expresses my intent quite
well..."

FilenameTest>>testCopyingToAnotherDirectory
| actualResult |
aFile copyToDirectory: aFileDirectory.
self should: [actualResult = 'your expected result is
coded here']
	description: 'Should copy a file to the indicated
directory'. 

On a side note, by defining the message(s) Filename
responds to in a test beforehand you have a much
better chance of winding up with a useful and clear
interface. Writing a broken test first encourages
giving the object responsibility. You don't worry
about how it's going to actually going do it's thing.
You just code in the interface which makes your life
the simplest you wish it to be.

The final step of writing your first broken test is to
write the desired message which will create a new
Filename instance.

testCopyingToAnotherDirectory
| actualResult aFile |
aFile := Filename new. "<-doesn't have to be 'new'.
Just what you desire."
aFile copyToDirectory: aFileDirectory.
self should: [actualResult = 'your expected result']
	description: 'Should copy a file to the indicated
directory'.

In Squeak, you may have to write a stub class Filename
in order to get the code to compile. After successful
compilation the code will of course not pass. Which is
good. We want it to be broken as we're writing our
tests first, not last. It's an very important first
small step.

When we program by intention (a.k.a.- test first
coding, Test Driven Development) we just say what we
want but we don't say how to do it. 

If it's an explanation test which will be sent to
others to illustrate a point we need not be the one's
to implement the code to make it pass.

It would be most helpful if you might clarify the
desired intent in a test for us. If you need further
advice how to write an explanation unit test let me
know.

If you're curious as to what a complete test first
coding session looks like (from the first broken test
to the point all tests pass) check this link out:

http://xprogramming.com/xpmag/recordmap.htm

For more on the sUnit unit testing framework see:

http://sunit.sourceforge.net/manual.htm

Also, might be of interest:
http://xprogramming.com/xpmag/testFirstGuidelines.htm

Thanks for listening,

Anthony

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



More information about the Squeak-dev mailing list