in reply to Unit testing OS rich code

I think I would create a temporary directory & files and just run your code against that.

That way you don't have to mock the os functions at all. In your example it looks easy enough - just touch some file names. Of course if you need to do more complex things, maybe reading info from the files, you may have to keep a set of test files that you copy into your temp dir before you begin the tests.

Replies are listed 'Best First'.
Re^2: Unit testing OS rich code
by Voronich (Hermit) on Oct 12, 2011 at 15:54 UTC
    Eh. I really don't like having filesystem state for tests. I think I'm just avoiding the inevitable here. I've got the same issues coming fast on the horizon for database interactions as well.
    Me
      I really don't like having filesystem state for tests.

      If your code manipulates the filesystem, how will you know if it works unless you test that it manipulates the filesystem?


      Improve your skills with Modern Perl: the free book.

        At some point you have to trust that the primitives are doing their job. Otherwise "full code coverage" would always include unit tests that cover perl itself. So keeping an onion-skin layer on top allows me to preserve testability.
        Me
Re^2: Unit testing OS rich code
by DrHyde (Prior) on Oct 17, 2011 at 10:14 UTC

    Using a temporary directory for test files is fine, until your tests need to do things that your user can't do. For example, my File::Find::Rule::Permissions needs to behave differently for root and for ordinary users, and the tests also need to create directories and files owned by all kinds of different users and groups.

    If my tests are running as an ordinary user, I simply can't create all the structures I need. And if running as root, they *shouldn't*. Dicking about with users and group membership just so my tests can run would be a Really Bad Idea. So I mock up a bunch of filesystem functions so I can test as an ordinary user. Then if my tests are running as root *and* there are appropriate user/group relationships already, I then also create a bunch of test files and run the tests for real.