Dropbear

New procps 3.3.0 for Debian

Written by

dropbear

in

,

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 responses to “New procps 3.3.0 for Debian”

  1. Luca Bruno Avatar
    Luca Bruno

    Maybe a naive answer, but wouldn’t DejaGnu do the trick? See http://www.gnu.org/s/dejagnu/

    Reply
    1. Craig Avatar
      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!

      Reply
      1. Luca Bruno Avatar
        Luca Bruno

        Glad to have helped 😉
        While we’re at it, you may even consider coupling dejagnu+valgrind, as currently done in LLVM testsuite: http://llvm.org/releases/2.7/docs/TestingGuide.html

        Reply
  2. Tobias Avatar
    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…

    Reply
  3. Serafeim Zanikolas Avatar
    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

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts