Coming soon after the upstream procps 3.3.0 being released, the Debian packages have been uploaded tonight.  The Debian packages have had the added benefit of being a day late by having a tiny 2 line patch to stop pgrep from crashing.

One regression that is on purpose, watch is currently not 8-bit clean again until I can sort out how to get the linking right with the new build process.

 

Testing Systems

The embarrassing problem with pgrep did start a discussion about testing, especially regression testing.  I’ve recently started using unit testing in my python programs and love the level of assurance those tests give me that I haven’t broken anything (to a degree anyhow). I’d really like to be able to type “make test” and have each of the programs run through a series of tests.

The problem with packages like procps (psmisc too) is that you really need to test the entire program, not just a stub, and that the program needs access to a know level of /proc.  The only thing I have seen that is even remotely what is needed is the bunch of scripts that coreutils uses which creates dummy files and directories to operate the commands on.  I expect we could do something similar with some scripts that create a known process but if anyone has a better idea about how to test a command line program let me know.

Enhanced by Zemanta

Comments (5)

    • Craig

      Not a naive answer in the least! I’ve had a look at that program and it looks like it will do exactly what I am after. I was looking around for something like this for psmisc for the same reason and couldn’t find anything for command line programs.

      I’ve already made a simple series of tests for pwdx and, while dejagnu has the same documentation problems that most GNU programs have, it is a very clever setup.


      PASS: pwdx no args
      PASS: pwdx pid 1 should give permission denied
      PASS: pwdx finds sleep in cwd

      Thankyou for pointing it out!

  1. Tobias

    Another idea would be a testsuite based on PID namespaces – this would give a very clean environment that can be populated with mock processes.

    One problem I see here: Some date (like the process size) is not very static…

  2. Serafeim Zanikolas

    probably there aren’t any, but for programs that rely exclusively on /proc (as opposed to process-related system calls), you could override the default location of the proc filesystem when a test flag is set

Comments are closed.