Re: test suite as CPAN module

2007-11-26 Thread Chris Dolan

On Nov 25, 2007, at 2:22 PM, David Cantrell wrote:


On Sun, Nov 25, 2007 at 01:47:58PM -0600, Chris Dolan wrote:


I've been working on Test::Virtual::Filesystem for a couple of
weeks.  It's a growing collection of interoperability tests that
should pass for any typical filesystem.


Could it also be used for detecting what features a mounted filesystem
supports?

eg, "does this filesystem support hard links" and "does this  
filesystem

support Unix-style permissions"?  The hard bit is doing that while
taking into account mount options.  eg, on Mac OS X, you can mount  
a UFS

filesystem (which supports Unix-style perms) but tell the system to
ignore permissions altogether.  The *really* hard bit is to do that as
an unpriveleged user and without making any changes to the fs.

If so, then I can see immediate uses for it in a couple of my  
projects.


I certainly can see a use for something like that, but Test-Virtual- 
Filesystem would not serve as a good base.  It deliberately tries not  
to probe the limits of the filesystem nuances (like how many symlinks  
do you have to follow before you get an ELOOP error = 5 on Linux, but  
at least 10 on other *nixes).


Chris


Re: test suite as CPAN module

2007-11-26 Thread nadim khemir
On Sunday 25 November 2007 20:47, Chris Dolan wrote:
> I've been working on Test::Virtual::Filesystem for a couple of
> weeks.  
> ...
> filesystems (like Fuse filesystems -- I use it for Fuse::PDF)
> ...
> Thoughts?

Fuse::PDF caught my eyes a few days ago (how could it not with that name ;) 
although I still wonder if it has any serious use) and having a test suite 
for a file system that can be reused is an excellent idea.

You're right, very few tests suits are reusable. I know of standard tests for 
C++ that vendors can qualify against but except that not much. Other domains 
tha could be interresting to have generic tests suits for are:

- load balancing/scheduling
- network protocol
- database

I'm planning to write a fuse based FS so your test suit will come handy.

Cheers, Nadim


Re: test suite as CPAN module

2007-11-25 Thread David Cantrell
On Sun, Nov 25, 2007 at 01:47:58PM -0600, Chris Dolan wrote:

> I've been working on Test::Virtual::Filesystem for a couple of  
> weeks.  It's a growing collection of interoperability tests that  
> should pass for any typical filesystem.

Could it also be used for detecting what features a mounted filesystem
supports?

eg, "does this filesystem support hard links" and "does this filesystem
support Unix-style permissions"?  The hard bit is doing that while
taking into account mount options.  eg, on Mac OS X, you can mount a UFS
filesystem (which supports Unix-style perms) but tell the system to
ignore permissions altogether.  The *really* hard bit is to do that as
an unpriveleged user and without making any changes to the fs.

If so, then I can see immediate uses for it in a couple of my projects.

-- 
David Cantrell | A machine for turning tea into grumpiness

  You know you're getting old when you fancy the
  teenager's parent and ignore the teenager
-- Paul M in uknot


Re: test suite as CPAN module

2007-11-25 Thread Andy Armstrong

On 25 Nov 2007, at 20:02, Andy Armstrong wrote:
I believe Apache::Test[1] is a suite of tests for an Apache server.  
I guess that's conceptually pretty similar to what you're doing?


[1] http://search.cpan.org/dist/Apache-Test/



Actually it does something slightly different from what I thought it  
did. It lets you build a test suite to verify a particular Apache  
based application I believe. Thanks to Paul Johnson for the correction.


--
Andy Armstrong, Hexten






Re: test suite as CPAN module

2007-11-25 Thread Andy Armstrong

On 25 Nov 2007, at 19:47, Chris Dolan wrote:

Questions:
* Are there other CPAN-hosted, generic test suites that I overlooked?



I believe Apache::Test[1] is a suite of tests for an Apache server. I  
guess that's conceptually pretty similar to what you're doing?


[1] http://search.cpan.org/dist/Apache-Test/

--
Andy Armstrong, Hexten






test suite as CPAN module

2007-11-25 Thread Chris Dolan
I've been working on Test::Virtual::Filesystem for a couple of  
weeks.  It's a growing collection of interoperability tests that  
should pass for any typical filesystem.  I've been pondering its  
place in the CPANiverse and am interested in any insights others may  
have.


* Unlike most of the Test::* modules, this is not a tool for writing  
tests.  Instead, it is a suite of complete tests that should be  
applied to a filesystem.
* It tests conformance to an API instead of an implementation.  In  
this case, the API is the collection of core Perl filesystem functions.
* The distro tests itself against a known, stable filesystem (/tmp or  
the equivalent) but is intended to be  used to test less stable  
filesystems (like Fuse filesystems -- I use it for Fuse::PDF)


I searched CPAN (admittedly lightly) for any similar suites and  
didn't find anything else expressly designed for such a purpose.


Questions:
* Are there other CPAN-hosted, generic test suites that I overlooked?
* What other stable, popular APIs would benefit from a reusable test  
suite?
* Is it worth pushing others to write and use test suites like this,  
possibly replacing existing ad hoc tests (see, for example, the  
Fuse.pm .t files)


I came across some non-Perl generic test suites (filesystem and  
otherwise), but many were optimized for benchmarking rather than API  
completeness.  I've read about a few others, like the Neon webdav  
test suite, but again saw little to nothing in the Perl world quite  
like that.


A notable exception is the PUGS test suite, which fits in this  
category in that it's intended to work against any Perl 6  
implementation.  The controversial Java TCK lives in this space too.   
In fact, the strong separation of Interface from Class in the Java  
world pushes towards this style of testing more naturally than in Perl.


In general, it has occurred to me many times that writing good tests  
can be as hard as writing good code, but that we rarely reuse them,  
unlike our code itself.


Thoughts?

Chris