Slashdot Mirror

← Back to Stories (view on slashdot.org)

Software Carpentry QMTest Testing Tool Released

Posted by timothy on from the building-a-better-bugtrap dept.

soundsop writes: "The first tool resulting from the winners of a design competition by the Software Carpentry project has been released. The QMTest tool is a testing tool to replace software such as XUnit, Expect and DejaGnu. An issue tracking tool, called QMTrack (a la Bugzilla) is forthcoming. It looks like the winning design proposals for a config tool (autoconf replacement) and a build tool (make replacement) are not being implemented."

3 of 63 comments (clear)

  1. A Windows version, too! by Tsar · · Score: 3, Informative

    I checked the downloads page and found a Windows download for QMTest 1.0. Can't wait to try it out.

  2. Replacing Expect? It's not a testing tool. by jdavidb · · Score: 4, Informative

    Kudos to the QMTest folks; I'm looking forward
    to the fruits of the software carpentry project. But, as Expect is an
    automation tool, not simply a testing tool, I don't think it'll exactly be "replaced."
    The well-known DejaGNU suite, written in Expect, might be a candidate for replacement, though.



    I use Expect all the time, but have never used it for testing. I tried DejaGNU a time or two,
    but never could figure it out. If you like Expect and like Perl, you might check out the
    Expect.pm module project; it's really come to fruition recently, and
    I've finally started doing that kind of thing in Perl instead of TCL/Expect.

    --
    Secession is the right of all sentient beings.
  3. XUnit still is more flexible by prototype · · Score: 3, Informative

    I think this is a nice product, but XUnit is still more flexible in regression and repetition testing. First off, this requires Python and an interface to Python from your application. That's not something I want to add to my system just to do testing. XUnit has basically been ported to every known language out there and is integrated into the languge. Also the way that you specify tests is maintained in a database. In a team development environment, you now have to have the db engine installed in everyone's workspace. While the db and python approach might offer a few more options maintenance wise, it makes things more complicated than they have to. XUnit has proven itself to be an excellent means of testing so if this is something new to you, try it out first before leaping into other technologies. No db or external language needed. Just my 2c worth on a quiet Christmas eve.

    liB