Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Shlomi Fish (918)

Shlomi Fish
  shlomif@iglu.org.il
http://www.shlomifish.org/
AOL IM: ShlomiFish (Add Buddy, Send Message)
Yahoo! ID: shlomif2 (Add User, Send Message)
Jabber: ShlomiFish@jabber.org

I'm a hacker of Perl, C, Shell, and occasionally other languages. Perl is my favourite language by far. I'm a member of the Israeli Perl Mongers, and contribute to and advocate open-source technologies. Technorati Profile [technorati.com]

Journal of Shlomi Fish (918)

Sunday February 04, 2007
04:49 PM

Ideal Setup for Testing an ANSI C Library

[ #32318 ]

This post is not strictly about Perl, but it is technical and about automated testing, which is a hot topic nowadays in the Perl world, so I decided to post it here.

I have written an ANSI C library called "Freecell Solver", which solves several variants of card solitaire. Now, the problem is that it doesn't have any automated tests yet, and I'd like to add some before I hack on it further.

Now, having attended Ori Peleg's presentation "Thoughts on Testing" on three different occassions, I became convinced that testing can only be done with dynamic languages, and writing complex test logic in C or Java should be avoided. Now, I may still be able to use perl for generating some simple C code for unit tests, that will then be compiled, or for system tests of the solver. However, it will probably not be very suitable for more complex unit or integration tests, because of its complex C extension API. So I'm looking for a better alternative.

One thing I've decided is that all my tests will produce TAP output, so I can use a good TAP analyser like Test::Run or TAPx::Parser, to process all the test scripts or a subset of them. If necessary, I will write a rudimentary TAP-outputting test framework in the language I choose.

Let me enumerate the options I see and what I think of them:

  1. Perl with XS - like I said - too complex and will require a lot of coding.

  2. Perl with Inline::C. This could hide away some of the complexity but I believe some complexity will still remain, as it still requires writing some code using XS.

  3. I could use SWIG to write my bindings. My former experience with SWIG, however, was not entirely positive as it doesn't handle pointers meaning arrays and other Cisms well, and often necessitates writing some glue code. By using SWIG, I could still write my unit tests in Perl.

  4. Python - I'm not entirely fond of it and think I'd like Ruby better.

  5. Ruby - I was told it has an even better extensibility API than Python, and it's also more similar to Perl. I do not intend any normal end-user to run the test suite so I can rely on Ruby being around.

  6. Tcl - should have a good extensibility API, but from what I know strings are null-terminated, and I dislike it quite a bit, so if at all - Ruby would be preferable. I mentioned it here for completeness' sake.

  7. Lua - small and with a good extensibility API. I don't think it's as rich as Ruby or Perl, but it probably won't matter too much for testing.

  8. The Io Language - similar to Lua in size. It's very interesting as a language, but I had some problems deploying it properly on my system, and I dislike its syntax for its "[object][space]method" convention and other mis-conventions like that.

  9. Smalltalk - the Squeak Virtual machine has a mind of its own, but there's GNU Smalltalk which works better with C. However, I dislike the Smalltalk syntax, and GNU Smalltalk is still a bit buggy, and I would probably prefer Ruby or Lua.

  10. Haskell and O'Caml are strongly typed and which will be an obstacle for testing.

  11. Scheme - I could use Guile or TinyScheme. However, Scheme tends to be overly verbose and to lack a lot of nice syntactic sugar. The same can be said of Common Lisp, but there there's also a lack of a decent ubiquitous implementation.

Maybe I missed a few players, but I think I covered the most prominent ones. Like I said, all the tests will emit TAP so their results can be analysed and summarised with the Perl TAP tools. At the moment, I'm leaning towards using either Ruby or Lua, but would love to hear what you think about all this.

Note that I don't need Unicode or Localisation or an interface to any third-party library, as my library relies exclusively on the ANSI C library. But I do need to handle binary data (with '\0' and all) properly.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.