Re: using test::unit for C++ unit tests

On Mon, May 27, 2002 at 05:59:35AM +0900, Phil Tomson wrote:
> I'm going to be starting on a C++ development project for a contract I'm 
> doing and I'd like to use the 'test-first' philosophy and develop unit 
> tests first.  Has anyone adapted any of Ruby's unit testing frameworks to 
> do unit testing for C++ classes?

Yes.  Our team does roughly 90% of our C++ testing using Ruby.

> I'm thinking that there could be a couple of approaches:
> 1) make the C++ libraries Ruby extensions and instaniate the C++ objects 
> and pass messages to them on the Ruby side.

This is the solution we went with.  There are two options:

  a) Write the extensions as standard Ruby extensions, paying careful
  attention to resource management (as our C++ objects are reference
  counted, and Ruby uses a mark-and-sweep GC) as well as exception
  safety (Ruby exceptions must be translated to C++ exceptions and vice
  versa).  This isn't as difficult as it sounds, once you've done it
  once or twice.

  b) Write the extensions using Swig.  For complex templated classes,
  this doesn't seem to work well, but for simple classes, it works
  marvelously.  Exception safety issues still need to be considered, but
  if you can sacrifice a bit of speed, they are certainly less of an
  issue than with writing the extensions by hand.

> 2) make some kind of wrapper class (in C++) that gets used to instantiate 
> and call methods and then returns some error code.  Compile this wrapper 
> into an executable binary that gets called from Ruby with error codes 
> being passed back:
> errors = 'exercise <some params>'

I've done this, too.  It's more convenient sometimes, but results in
less maintainable tests.  I find a mix of #1 and #2 to be a reasonable
compromise.

> 3) a variation on #2 that uses expect.rb.

I'm not sure what you mean by this.  Can you elaborate?

(Some of our tests for socket-based applications are done using a
variation of expect.rb that is capable of listening for multiple
"chains" of messages simultaneously.  Is this what you are describing?)

> While #1 seems perhaps to be the cleanest choice, we don't have much time 
> to set all of this up, so creating the extensions might take longer than 
> what we'd like.

I don't think any of the above options necessarily has a clear advantage
in terms of time.  What I've found is that getting the first version of
an extension right may take some time, but that time is soon gained back
by a) the development time of the tests is drastically reduced, since
you don't have to recompile the tests whenever they change, and b)
adding a new test is very easy.

> Can anyone who has done this offer some pointers?
> 
> Phil 

Hope this helps,

Paul