RE: run C++ TAP output? (even easier)

[leif . eriksen]

 Another option is to use IPC::System::Simple.

The driver script is a neat idea, I used this variation for testing my
harness wrapped around my Utils C library

Say I had C code in a Utils library, one source file which might have
this code

Utils.c
/**
  * internal function
  */
static int hexChar2Int (unsigned char ch) {
if (ch = '0'  ch = '9') return ch - '0';
if (ch = 'A'  ch = 'F') return ch - 'A' + 10;
return -1;
}

The test harness might look like this

Test_Utils.c
#include tap.h
#include Utils.c
isInt(hexChar2Int('0'), 0);
isInt(hexChar2Int('Z'), -1);

And the perl driver could look like this

Test_Utils.t
use IPC::System::Simple;
...
run('test_Utils');

or

run('test_Utils', @args);

Note how the function we're testing is declared static, but we include
the C file in the harness - this is a neat way to get at the internal
functions and state variables in C code, if your testing down at that
level.

IPC::System::Simple give me finer grained control over testing return
codes from calls to run various harnesses

As with Ovid's code I options as to how I want to run this.

perl -MTest::Harness -e 'runtests(qw(test_Utils.t))'
prove test_Utils.t
make test

L

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Friday, 9 March 2007 11:19 PM
To: [EMAIL PROTECTED]; perl-qa@perl.org
Subject: Re: run C++ TAP output? (even easier)

If you want things to be *really* easy to run test suites in multiple
languages, do this.

First, make sure that all test programs are executable.  Then use this
driver program:

   $ cat bin/run.pl 
   #!/usr/bin/perl
 
   use strict;
   use warnings;
 
   my $prog = shift;
   unless ( -e $prog  -x _ ) {
   die Cannot find or execute ($prog);
   }
   exec $prog;

Then 'find' all executable files and use the '--exec' option with
runtests to execute all of them with the 'bin/run.pl' program:

  $ find t/ -perm /u+x -type f | xargs runtests --exec bin/run.pl
  t/tap Failed 1/3 subtests 
  t/perl...ok   
  
  Test Summary Report
  ---
  t/tap.exe (Wstat: 0 Tests: 3 Failed: 1)
Failed tests:  2
  Files=2, Tests=5,  0 wallclock secs ( 0.04 cusr +  0.00 csys =  0.04
CPU)

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
**
IMPORTANT
The contents of this e-mail and its attachments are confidential and intended
solely for the use of the individual or entity to whom they are addressed.  If
you received this e-mail in error, please notify the HPA Postmaster, [EMAIL 
PROTECTED],
then delete  the e-mail.
This footnote also confirms that this e-mail message has been swept for the
presence of computer viruses by Ironport. Before opening or using any
attachments, check them for viruses and defects.
Our liability is limited to resupplying any affected attachments.
HPA collects personal information to provide and market our services. For more
information about use, disclosure and access see our Privacy Policy at
www.hpa.com.au
**

Re: run C++ TAP output? (even easier)

[Geoffrey Young]

Ovid wrote:
 If you want things to be *really* easy to run test suites in multiple
 languages, do this.

another option is this:

  http://people.apache.org/~geoff/test-more-separately.tar.gz

which illustrates how to separate planning, etc in perl but use a
foreign tap producing faile - something we do all the time over in httpd
land...

anyway, in that tarball t/plan.t calls

  print qx!perl t/response.pl!;

so alter that call to execute whatever shell command you like, say

  print qx!./response.exe!;


 and alter response.exe to emit tap using $language and you're all set.

HTH

--Geoff

Re: run C++ TAP output? (even easier)

[Michael G Schwern]

Julien Beasley wrote:
 Well at my last job, we had hundreds of test files.. and most of them were
 really fast because we wanted to keep the total time to a minimum. Even
 then, it took over five minutes to run all of our tests, and that was
 getting to be Too Long. So I could definitely see in a case like that that
 the overhead of starting a new interpreter for each file would add up

$ time perl -wle 'for (1..$ARGV[0]) { system perl -e 1 }' 1000

real0m5.358s
user0m1.328s
sys 0m3.474s

And that's on my dinky little Macbook.

Firing up a new perl interpreter for each test will not be your bottleneck
if your tests actually do anything.