All the Perl that's Practical to Extract and Report

More on FFR::Permissions

drhyde on 2003-07-23T10:15:56

If anyone has any suggestions for sane ways of thoroughly testing this module, please let me know. Unfortunately, a complete test suite would need to be able to change its EUID and consequently would need to be run as root. And to make matters worse, many machines won't have sufficiently complex user/group relationships *and* even the default usernames and group names aren't particularly predictable across platforms. Right now, the only test is that it loads and compiles, and users just have to trust me that I have tested the functionality myself.

Can't you just mock the system side?

Adrian on 2003-07-23T14:09:36

If it were me I'd mock everything that talks to the system:

  • I'd mock getpwent() and getgrent() so I could have known UID/group mappings.
  • I'd mock stat() so I could get known results rather than muck around creating a bunch of files with specific permissions.
  • I'd wrap all acccess to $> within a subroutine so I could override it to give known results during testing.

Re:Can't you just mock the system side?

drhyde on 2003-07-24T13:09:45

Good ideas, and I'll look into it. But I get the feeling that this will result in the test suite being more complex than the module, so I'll need a test suite for the test suite :-)

Re:Can't you just mock the system side?

chromatic on 2003-07-25T18:26:22

That's why I write my tests first. The code tests the tests and the tests test the code. Ouroboric-driven development, that's what I always try to spell.