[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[ANN] FileSystem 0.1.0: Beta for me, Alpha for you

Francis Hwang

2/16/2005 2:40:00 PM

Greetings!

Next down my non-stop pipeline of absolutely necessary libraries that
only I seem to need: FileSystem, a library that will mock out File,
FileUtils, Dir, and other file-dependent built-in classes. It aims to
simulate an entire file-system in memory for the purposes of testing.

http://rubyforge.org/projects/f...

== HOW DOES IT WORK? ==

To use it in live code, you call get methods on the FileSystem module:

FileSystem.get_dir => Dir
FileSystem.get_file => File
FileSystem.get_file_utils => FileUtils
FileSystem.get_dir.entries( '.' ) => [ '.', '..', 'file1', ... ]

(I'm thinking about adding a voodoo.rb file that actually re-assigns
the constants Dir, File, and FileUtils, though I suspect this will not
be that usable in many cases.)

Then, to mock out that activity for a test code, simply call
FileSystem.mock= :

FileSystem.mock = true
FileSystem.get_dir => FileSystem::DirAdapter
FileSystem.get_file => FileSystem::FileAdapter
FileSystem.get_file_utils => FileSystem::FileUtilsAdapter
FileSystem.get_dir.entries( '.' ) => [ '.', '..', ... ]

== HOW COMPLETE IS IT? ==
Oh dear, not at all. Hence the release name: "Beta for me, Alpha for
you". I am now using it day-to-day, both at Rhizome[1] and my own
blog-publishing software, Dauxite[2]. So I know it works for me. It
currently handles basic issues of looking up paths, writing and reading
files, modification times, etc. It doesn't know anything about
symlinks, creation times, permissions. I suspect that if you tried to
mock a Windows system with it, that it would squeal like a 2-year-old.

I'm putting out today's release in hopes of getting bug reports. Please
file bug reports! Lots and lots of bug reports! Please be specific,
though. If you file a bug titled "Support Windows, you l4m3r" I won't
know where to start.

Thanks,
Francis "I'd mock out the air itself if my lungs were hot-swappable"
Hwang
http://f...

[1] Rhizome is the premier online resource in the field of new media
arts: It gets more than 1 million page views a month and contains the
world's largest online archive of new media art, at almost 1500 works.
[2] Dauxite is my own idiosyncratic, unreleased software. So it's not
as heavily tested as Rhizome, but I use it at least once a week, so
it's a good way to test something like FileSystem.
23 Answers

gabriele renzi

2/16/2005 2:47:00 PM

0

Francis Hwang ha scritto:
> Greetings!
>
> Next down my non-stop pipeline of absolutely necessary libraries that
> only I seem to need: FileSystem, a library that will mock out File,
> FileUtils, Dir, and other file-dependent built-in classes. It aims to
> simulate an entire file-system in memory for the purposes of testing.
>
> http://rubyforge.org/projects/f...

first: this seem incredibly cool.
second: would'nt something like "FS::Mock" or "test/filesystem" be a
better name? when I first saw this on rubyforge I thought it was some
kind of VFS :)

Francis Hwang

2/16/2005 2:56:00 PM

0


On Feb 16, 2005, at 9:49 AM, gabriele renzi wrote:

> Francis Hwang ha scritto:
>> Greetings!
>> Next down my non-stop pipeline of absolutely necessary libraries that
>> only I seem to need: FileSystem, a library that will mock out File,
>> FileUtils, Dir, and other file-dependent built-in classes. It aims to
>> simulate an entire file-system in memory for the purposes of testing.
>> http://rubyforge.org/projects/f...
>
> first: this seem incredibly cool.

Thanks! It's already been pretty helpful for me, hopefully it'll be
useful to others too.

> second: would'nt something like "FS::Mock" or "test/filesystem" be a
> better name? when I first saw this on rubyforge I thought it was some
> kind of VFS :)

I think it's related to how you're supposed to access the lib in your
live code. The name "FileSystem" to me seems less distracting in
production code than something like "FS::Mock" ... It's only being
mocked out in your tests.

I'm not 100% happy with the current form of access either: Typing
"FileSystem.get_file" when you really just want "File" is sort of
cumbersome. But it just seemed like the least broken thing I could go
forward with while I figured out something else. When we talked about
this at Ruby-NYC a few weeks ago, Patrick was saying I could write a
file to change the definitions of File, FileUtils, Dir, etc. Maybe
that'll be the way to go.

Anyway, I'm very very open to suggestions regarding the name and/or how
to access it.

Francis Hwang
http://f...

djberg96

2/16/2005 2:59:00 PM

0

Francis Hwang wrote:
> Greetings!
>
> Next down my non-stop pipeline of absolutely necessary libraries that

> only I seem to need: FileSystem, a library that will mock out File,
> FileUtils, Dir, and other file-dependent built-in classes. It aims to

> simulate an entire file-system in memory for the purposes of testing.

Oh, dear. I believe we have our first significant name collision -
your package and Mike Hall's filesystem package, and they do different
things.

Caveat Programmor.

Regards,

Dan

Anders Bengtsson

2/16/2005 3:08:00 PM

0

Francis Hwang wrote:

> Next down my non-stop pipeline of absolutely necessary libraries that
> only I seem to need: FileSystem, a library that will mock out File,
> FileUtils, Dir, and other file-dependent built-in classes. It aims to
> simulate an entire file-system in memory for the purposes of testing.

Very cool! I was looking for something similar to this some time ago,
but figured it would be too much work to implement it. I'm glad you made
a different decision! :)

Did you examine the possibility to override the methods in the standard
IO and File classes, so that it could be more transparent?

/Anders

--



Ben Giddings

2/16/2005 3:08:00 PM

0

On Feb 16, 2005, at 09:39, Francis Hwang wrote:
> To use it in live code, you call get methods on the FileSystem module:
>
> FileSystem.get_dir => Dir
> FileSystem.get_file => File
> FileSystem.get_file_utils => FileUtils
> FileSystem.get_dir.entries( '.' ) => [ '.', '..', 'file1', ... ]
>
> (I'm thinking about adding a voodoo.rb file that actually re-assigns
> the constants Dir, File, and FileUtils, though I suspect this will not
> be that usable in many cases.)
>
> Then, to mock out that activity for a test code, simply call
> FileSystem.mock= :
>
> FileSystem.mock = true
> FileSystem.get_dir => FileSystem::DirAdapter
> FileSystem.get_file => FileSystem::FileAdapter
> FileSystem.get_file_utils => FileSystem::FileUtilsAdapter
> FileSystem.get_dir.entries( '.' ) => [ '.', '..', ... ]

Hi Francis,

I like the idea, and the idea of mocking out things like filesystems is
very important. Just a few comments on the naming of things:

If the class is mainly just a test construct and/or a proxy for actual
Filesystem calls, maybe "Test" or "Proxy" should be part of the class
name. Secondly, method names that start with "get_" seem pretty
un-rubyish. They feel more like Java getFoo() and setFoo() type
functions. Maybe it would make sense to rename them just dir, file,
file_utils and dir_entries?

Ben

P.S. If you ever decide to mock out a human being, let me know. This
morning in the shower I was wondering how I can mock out the person who
has to push a button on an embedded device I'm working on. Sure, I can
easily mock out the register that pushing the button supposedly
changes, but that kinda defeats the purpose of the test.

Ilmari Heikkinen

2/16/2005 3:31:00 PM

0


> P.S. If you ever decide to mock out a human being, let me know. This
> morning in the shower I was wondering how I can mock out the person
> who has to push a button on an embedded device I'm working on. Sure,
> I can easily mock out the register that pushing the button supposedly
> changes, but that kinda defeats the purpose of the test.

Robots, man, robots. Preferably small dancing ones.


--
66. The regions beyond these places are either difficult of access
because of their excessive winters and great cold, or else cannot be
sought out because, of some divine influence of the gods.

djberg96

2/16/2005 3:36:00 PM

0

Ben Giddings wrote:

> P.S. If you ever decide to mock out a human being, let me know.

You smell and your momma dresses you funny. How's that?

Oh...mock "out". ;)

Regards,

Dan

Francis Hwang

2/16/2005 4:07:00 PM

0

On Feb 16, 2005, at 9:59 AM, Daniel Berger wrote:

> Oh, dear. I believe we have our first significant name collision -
> your package and Mike Hall's filesystem package, and they do different
> things.

Aw, for Pete's sake. I guess that's what I guess for not checking RAA
...

So I guess I better rename my FileSystem to something else. Suggestions?

Francis Hwang
http://f...

Francis Hwang

2/16/2005 4:13:00 PM

0


On Feb 16, 2005, at 10:07 AM, Anders Bengtsson wrote:

> Very cool! I was looking for something similar to this some time ago,
> but figured it would be too much work to implement it. I'm glad you
> made
> a different decision! :)

I've actually done this, in half-hearted ways, three separate times in
three separate apps ... So this lib is my attempt to do it once, and
correct ...

> Did you examine the possibility to override the methods in the standard
> IO and File classes, so that it could be more transparent?

More transparency is important, yeah, but maybe I won't want to
redefine methods on already existing classes & modules. Method coverage
is currently really spotty, so if I redefined, say, File.mtime but not
File.ctime, your test code would be mixing up its calls against the
MockFileSystem with its calls to the real file system ... pretty
confusing, I think.

Might be better to simply undefine and redefine those constants:

Object.send( :remove_const, :File )
class File
...
end

Though it's quite possible that that could be really nasty, too. I'll
have to poke around for a while to see.

Francis Hwang
http://f...

Francis Hwang

2/16/2005 4:16:00 PM

0


On Feb 16, 2005, at 10:08 AM, Ben Giddings wrote:
> If the class is mainly just a test construct and/or a proxy for actual
> Filesystem calls, maybe "Test" or "Proxy" should be part of the class
> name. Secondly, method names that start with "get_" seem pretty
> un-rubyish. They feel more like Java getFoo() and setFoo() type
> functions. Maybe it would make sense to rename them just dir, file,
> file_utils and dir_entries?

Yeah, good points. This may all be mooted if I decide to just replace
Dir, File, FileUtils, etc with some strange magicks. We'll see.

> P.S. If you ever decide to mock out a human being, let me know. This
> morning in the shower I was wondering how I can mock out the person
> who has to push a button on an embedded device I'm working on. Sure,
> I can easily mock out the register that pushing the button supposedly
> changes, but that kinda defeats the purpose of the test.

Well, this won't directly solve your problem, but for an idea of how
you might solve this, you could look at EasyPrompt, which does the same
for a command-line user: http://easyprompt.ruby... In
particular, check out the MockCommandLineUser.

Funny thing is, code that uses EasyPrompt (and is thus more mockable)
looks a lot like the example code people use when talking about
continuations in web apps ... leading me to believe that
continuation-based web apps would be tons easier to test across
multi-step processes. Not that I've ever used continuations, just
saying.

Francis Hwang
http://f...