Having done the initial work to get most of FreeBSD's regression testing
infrastructure producing Test::Harness TAP compatible output, I've started
putting together a C library that makes it easier to write tests in C.
This is a few hours work at the moment, but it's functional, and I'd
appreciate
Michael G Schwern wrote:
> On Mon, Dec 06, 2004 at 10:00:32AM -0000, Clayton, Nik wrote:
>> Then you have one of ok() or ok2() at your disposal. ok()'s first
>> parameter is the code to test. The second parameter is the test name.
>> This is a printf()like format
Michael G Schwern wrote:
>> An alternative is to drop the ugly ok2() and force the test writer to
>> use:
>>
>> ok(1 == 2, "");
>>
>> I prefer that since I want to make it hard for people to avoid giving
>> a test a name, er, comment.
>
> At the very least some better name than ok2().
Na
Andrew Savige wrote:
> 1) You might be able to steal some implementation ideas from:
>
> http://cutest.sourceforge.net/
>
> This is a very simple C Unit Testing framework.
> In particular, it keeps state in a CuTest struct which is passed
> around as the first (mostly hidden) parameter to most fu
> > > I hope you're not emulating Test::More's exit code == # of
> > > tests failed "feature" that I'm planning on getting rid of.
> >
> > Right now that's exactly what I'm doing. The test suite for libtap
> > consists of a series of Test::More test files and a series of C files that
> > try and
Clayton, Nik wrote:
>> You might want to throw it in as an option. I'm going to change
>> Test::More so it no longer mucks with the exit code by default, you'll
>> have to turn this feature on.
>
> OK. I'll track changes to Test::Harness, and libtap'l
I've set up anonymous read-only access to my Subversion repo, so
anyone that wants to play with libtap easily can now:
svn checkout svn://jc.ngo.org.uk/nik/libtap/trunk/
Share and enjoy.
N
> --- "Clayton, Nik" wrote:
> > Any "Writing thread safe libraries for dummies" texts you
> > could point me at?
>
> I recommend "Programming with POSIX Threads" by David Butenhof.
Thanks.
> Re the varargs ok() business, I assume yo
> I use Text::Differences for this, as it will show which lines are
> different, rather than just the first 50 characters. Much
> easier for me to diagnose problems.
Something I put at the top of a lot of my test scripts is:
if(eval "require Test::Differences; 1") {
no warnings 'redefine';
> > http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards
> >
> > On coding standards:
I'd add an additional:
* Make sure your tools enforce them, and make complying with them
as simple as possible.
To be honest, I don't care if someone's house style is for TAB to indent
2, 4, or 8 charact
> I /think/ he means what the tab key's effect is when typed in
> his editor of choice
Correct. Hitting TAB should indent to the correct level for the current
context. I don't especially care whether the editor does by inserting
actual TAB characters or a bunch of spaces.
I've normally got eno
> > I've normally got enough going on in my head when writing code, worrying
> > about the house style should not be one of them.
>
> Wrong. It should be. You write, and someone else - or yourself - has to
> maintain the code later. This means that you have to write with style and
> maintainabilit
> #2 and #3 look similar but act differently. Unfixable by about 16
> years. Fine.
On that thought -- how do people feel about describing a mechanism for
extending TAP now, while there's only one large consumer of it, rather
than later, when there are (hopefully) going to be multiple disparate
u
> On Sun, Feb 20, 2005 at 10:19:09AM +0100, Johan Vromans wrote:
> > http://www.petdance.com/random/tap.html
> > > Everyone: I still need more comments. Pete Krawczyk's the only one to
> > > provide complaints yet.
>
> There's no discussion of the exit code of the test process.
"Descrip
> I specifically left that out. It's an issue that Test::More deals
> with, but doesn't have to. TAP.pod really only deals with
> TAP, not the libs that create it.
Sort of.
1. qq{will generate
FAILED tests 1, 3, 6
Failed 3/6 tests, 50.00% okay}
That's T::H output.
2. qq{Currently T
> On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote:
> > A quickie sample implementation to add more meat. I didn't apply yet
> > mainly because I'm wondering if we shouldn't bail and do a complete
> > roll-back (eg. don't generate a Build script) if there are any failed
> > require
> * Write tests!
libtap's tests are implemented by creating a set of reference test scripts
using Test::More, capturing the output from those, and then making sure
that the output from the same test implemented using libtap is the same
(modulo changes in line numbers and filenames in the test outp
I'm copying this back to the mailing list because I thought it might be
more generally useful.
> a. what kind of application it is ?.. requirement?
It's our external mail system. Broadly, this consists of Sendmail plus a
whole host of locally developed or open source software working in tandem
t
Folks,
Can anyone recommend any texts on testing applications and libraries that are
supposed to work with threads? How to force race conditions, that sort of
thing?
N
All,
There seems to have been a change in the output format for test
failures semi-recently.
Given this test script:
#!/usr/bin/perl
use Test::Harness 0.48;
use Test::More 0.60;
plan tests => 2;
ok(1, 'test 1');
ok(0, 'test 2');
I get this output:
1..2
ok 1
All,
A quick sanity check of an API, if you'd be so kind. I'm working on a
series of modules to make sure that our production servers are built
correctly.
I'm just working on Test::User and Test::Symlink.
Test::User exports user_ok and homedir_ok.
user_ok(name => 'username', ..., 'Test na
> On Tue, Jun 28, 2005 at 03:24:51PM +0100, Clayton, Nik wrote:
> > user_ok(name => 'nik', uid => 1000, shell => '/bin/tcsh',
> > 'Check nik\'s account');
>
> My only thought is I would use a hash ref.
>
22 matches
Mail list logo
