Mock/Fake network fileshare for my new modules Test Suite

[Galdor]

Dear esteamed Monks of Perl - I am writing a script/suite/module to recurse and test the various files/folders found on a network filesystem that need to have certain naming conventions, folder structures, relative paths to each other, and contents in certain files (similar to Perls' Manifest, Changes, ...) - in fact quite similar to Perl Modules structures..(actually this is to test the quality of a PROD and DEVEL ITIL DML)

I have been persuaded to use TDD (Test Driven Development) and would like to start with this project.

My question is this: I am pursuing test driven development - so can I have a test (mock) "share" (Windows UNC in this case) that I can "load" with samples of both correct and incorrect standards to run the tests against (with ok(); is(); isnt();, etc)?

Also this would go into the modules distribution (as the test suite) so it would have to be as small as possible (the real DML is enormous with massive files, *.iso, *.cab, *.7z, *.zip, etc).

PS - Another (advanced) point is that I am developing my code on laptop - so how can I "switch" test suite (prove command) to run against a) network share when in office, and b) "mock" share when traveling/at home? Also to switch between production and test DMLs

PPS - If there are any modules that already do this kind of thing (testing directory structure integrity) please give a shout out :-)

[afoken]

can I have a test (mock) "share" (Windows UNC in this case) that I can "load" with samples of both correct and incorrect standards to run the tests against

If you are on Windows, you can map local directories to other drive letters: net use v: \\localhost\c$\strawberry works just fine, everything at C:\strawberry is now also available at V:\. Use net use v: /delete to remove that mapping.

Note that you also can use an explicit share instead of the automatic share c$.

To test, you would set up two directories, "right" and "wrong", and map and unmap them as needed:

#!/usr/bin/perl
use strict;
use warnings;

# Untested!

sub run_tests()
{
    # your job! Maybe just system("prove");
}

for my $subdir ("right","wrong") {
    system("net use t: \\\\localhost\\testsuite\\$subdir");
    run_tests();
    system("net use t: /delete");
}

how can I "switch" test suite (prove command) to run against a) network share when in office, and b) "mock" share when traveling/at home? Also to switch between production and test DMLs

#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

# Untested!

sub run_tests()
{
    # your job!
}

sub where_am_i()
{
    # read $ENV{'WHERE_AM_I'}, ping a server, look up host name, whate
+ver works
}

my $share={
    homealone  => "\\\\localhost\\testsuite",
    office     => "\\\\develserver\\project42\\testsuite",
    testserver => "\\\\testingfiler\\somewhere\\tests4proj42",
    prodserver => "\\\\bigfiler0815\\elsewhere"
}->{ where_am_i() } // die "Unknown environment";

for my $subdir ("right","wrong") {
    system("net use t: $share\\$subdir");
    run_tests();
    system("net use t: /delete");
}

Alexander

[Anonymous Monk]

Network shares mounted locally should behave the same as local filesystems for basic operations (open, read, write). If you're only listing directories and testing filenames, it should work just fine to create the file structure locally and test against that. If you need to simulate large file sizes, you could abstract out the fetching of the file size into a sub get_size { my ($filename) = @_; ... }, and then mock that during testing (more advanced monks may know if it's possible to mock -s directly...?).

However, if you're going to be doing other things like file locking or reading file attributes other than size and modification time, support for that can vary wildly depending on protocol, software versions, etc. Also of course each software and protocol may have some other small quirks here and there.

As for switching locations to test against, if it's a single test program, then a command line arg should be enough; if it's a suite of test scripts, an environment variable is easiest.

To keep your test suite small, you could include a script that generates the fake directory structures for you (for example, create a temp dir via File::Temp, generate the files there, and test against that).

What OS will you be running on? Also, if you haven't seen them yet, the excellent Path::Class and File::Find::Rule modules should help you in navigating the directory structure.

(A bit of Googling brings up Filesys::Virtual::Async and Test::Virtual::Filesystem, maybe those can help too.)

[Anonymous Monk]

Here's a PerlMonks post in which Athanasius shows how a class can overload -X operations performed on itself (that would require that you use this class for all -s calls). According to this StackOverflow post, overriding the file test operators isn't directly possible. stat can be mocked, but I haven't yet found out if it's possible to affect -X.

[DrHyde]

Example of mocking stat(): the File::Find::Rule::Permissions tests.