On Wed, 2005-01-26 at 19:36 -0800, Ovid wrote:
> Perhaps we have something else different on our systems, but when I'm
> processing "extra" lines, $result{number} is false.
Yeah, I see what I was thinking. Here's a patch that makes the
Test::Harness tests all pass by default by adding a flag t
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 18:51 -0800, Ovid wrote:
> Odd. I think the problem was in looking for undefined values; at
> least,
> I remember ending up with that while writing the patch and running
> the
> Test::Harness tests.
Perhaps we have something else di
On Wed, 2005-01-26 at 18:51 -0800, Ovid wrote:
> This line:
>
> > +elsif ($result{number} and my $extra = $self->_is_extra_line(
> > $line ))
>
> Always fails to collect the data I need because $result{number} is
> false when the extra data is being accumulated. Thus, I changed it to:
>
>
--- Ovid <[EMAIL PROTECTED]> wrote:
> And this is confusing me because the next line actually uses the
> $result{number} but the code still works.
>
> elsif (!$result{number} and my $extra = $self->_is_extra_line(
> $line )) {
> my $test = $totals->{details}[$result{number} -
All~
I have been struggling with my internet for the past 4 days, so this
weeks summary will be part of a "double feature" fortnight's summary
next week. Figured that I would provide advanced notice though...
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
--- Ovid <[EMAIL PROTECTED]> wrote:
> > +elsif ($result{number} and my $extra = $self->_is_extra_line(
> > $line ))
>
> Always fails to collect the data I need because $result{number} is
> false when the extra data is being accumulated. Thus, I changed it
> to:
>
> elsif (!$result{number}
--- chromatic <[EMAIL PROTECTED]> wrote:
> (and displaying better diagnostics on success or failure), here's a
> small patch to Test::Harness::Straps to collect the diagnostic
> information currently dumped to STDERR and to store it in the test
> data structure for Straps users to collect:
OK, I h
did a fresh checkout and build... large number of dynclasses tests failed.
I then made clean, configured with prefix=`pwd`... now the build itself fails:
oolong:~/research/parrot_strings coke$ make
Compiling with:
xx.c
cc -g -pipe -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe
-fno-c
On Wed, Jan 26, 2005 at 06:28:20PM -0500, David Golden wrote:
> But is there any reason they can't be run in the same process?
In general I think its a bad idea for the test and the thing which generates
its output to be in the same process. Why? Because then how do you, the
user, change the out
Hi all,
As threatened in comments on Ovid's journal about colorizing test output
(and displaying better diagnostics on success or failure), here's a
small patch to Test::Harness::Straps to collect the diagnostic
information currently dumped to STDERR and to store it in the test data
structure for
Michael G Schwern wrote:
On Wed, Jan 26, 2005 at 05:55:24PM -0500, David Golden wrote:
While this simple example just has the test function shove a reference to a
hash onto a global array @{$Tester::RESULTS{$filename}}, the test function
could just as easily create an object (Test::Object::Ok, Te
On Wed, Jan 26, 2005 at 05:55:24PM -0500, David Golden wrote:
> While this simple example just has the test function shove a reference to a
> hash onto a global array @{$Tester::RESULTS{$filename}}, the test function
> could just as easily create an object (Test::Object::Ok, Test::Object::Is,
>
On Jan 26, 2005, at 5:12p, Andy Lester wrote:
I would love to hear your thoughts and ideas on structures of results.
Here's approximately what I'd like, which could easily be passed to a
template. This is just a brain dump, feel free to tear it apart. A few
of the values are provided for convenie
Andy Lester wrote:
I would love to hear your thoughts and ideas on structures of results.
Wild brainstorming here -- the issue seems to be with the fact that test
success and failure is associated with a printed result. What if the tests
instead pushed a results object onto some global data stac
On Jan 26, 2005, at 3:48p, [EMAIL PROTECTED] wrote:
My main gripe is that the infrastructure for it is less OO friendly.
The
example with the HTML output was awesome..until i looked at how it
was
done. The inability to get a data structure back for the test results
is very,
very frustratin
On Wed, Jan 26, 2005 at 12:58:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote:
> --- [EMAIL PROTECTED] wrote:
> > My main gripe is that the infrastructure for it is less OO friendly.
> > The example with the HTML output was awesome..until i looked at
> how
> > it was done. The inability to get a d
Quoting Ovid <[EMAIL PROTECTED]>:
The problem is not with Test::More. It's with Test::Harness. Using
Test::Harness::Straps will get you partway there.
duly noted. Test::More just has all of the sugar that helps make my
tests look
cleaner. Sorry, Test::More! Damn you, Test::Harness!!!
-j
On Wed, Jan 26, 2005 at 02:48:56PM -0600, [EMAIL PROTECTED] wrote:
> My main gripe is that the infrastructure for it is less OO friendly. The
> example with the HTML output was awesome..until i looked at how it was
> done. The inability to get a data structure back for the test results
> is
--- [EMAIL PROTECTED] wrote:
> My main gripe is that the infrastructure for it is less OO friendly.
> The example with the HTML output was awesome..until i looked at
how
> it was done. The inability to get a data structure back for the test
> results is very, very frustrating.
Well, I think
Quoting Michael G Schwern <[EMAIL PROTECTED]>:
I would prefer it if people would stop associating Test::More with
"testing using .t files". Test::More is a simple collection of testing
functions. How you use it is not restricted by the module. Test::Inline
and Test::Class both use Test::More for
On Mon, Jan 24, 2005 at 01:35:00PM -0800, Ovid wrote:
> Test::More is also good if you're doing smaller projects. All of my
> CPAN modules now require Test::More. It's very easy to use and you can
> get up to speed faster with Test::More than most of the other testing
> tools (besides Test::Simpl
On Mon, Jan 24, 2005 at 04:11:56PM -0500, Ian Langworth wrote:
> I'm taking a software development class this semester which will involve
> writing extensive object-oriented code. My partner and I are trying to
> decide whether to use Test::Unit, ::Class, or ::Inline for our test scripts.
>
> I
Hello,
Here's a story of how I've been able to improve the quality of my Perl
development process significantly:
Benefits of a Real World switch from CVS to darcs
http://mark.stosberg.com/Tech/darcs/cvs_switch/
Switching my source control system has made a big difference in my
ability t
François" PERRAD <[EMAIL PROTECTED]> wrote:
> I add some informations about building with MinGW32 in the file
> "README.win32".
> With --gc=malloc [ ... ] After a small patch, what's build.
Thanks, applied.
> # Failed test (t/pmc/nci.t at line 36)
> # got: 'loaded
> # dlfunced
> #
24 matches
Mail list logo
