Dave Whipp <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>> I'm not arguing that the unit tests themselves shouldn't carry
>> documentation, but that documentation (if there is any) should be
>> aimed at the perl6 developer.
>
> Depends what you mean by "perl6 developer": is that the interna
Piers Cawley wrote:
I'm not arguing that the unit tests themselves shouldn't carry
documentation, but that documentation (if there is any) should be
aimed at the perl6 developer.
Depends what you mean by "perl6 developer": is that the internals
people, or the lucky user?
Unit tests should be
"Dave Whipp" <[EMAIL PROTECTED]> writes:
> "Chromatic" <[EMAIL PROTECTED]> wrote:
>> Advantages of inline tests:
>> - close to the documentation
>> - one place to update
>> - harder for people to update docs without finding code
>
> Plus, it gives us a mechanism to validate example-code
> within d
On Tue, Nov 12, 2002 at 12:03:01PM -0800, Dave Whipp wrote:
> Maybe there's a terminology problem: but what is a regression test? In my
> world, we create a regression by running existing tests: we don't write a
> special test suite for the regression. There may be a small number of tests
> that w
Dave Whipp:
# Maybe there's a terminology problem: but what is a regression
# test? In my world, we create a regression by running existing
My understanding is that a "regression test" is basically a test to make
sure a bug doesn't come back once it's been fixed.
--Brent Dax <[EMAIL PROTECTED]>
On Tuesday, November 12, 2002, at 12:03 PM, Dave Whipp wrote:
I'm happy pick a format and run with it. When we've a few
micro-sections
done, then we can review. I see (in another post) that Mike has opted
for
external, "without objection". I'm abstaining. But I would like to see
executable exa
On Tue, Nov 12, 2002 at 11:21:09AM -0800, Brent Dax wrote:
> Michael Lazzaro:
> # On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote:
> # > Why use POD like this instead of a more atomic version of the
> # > standard testing format used by Perl 5? We can use the directory
> #
> # Dunno, lo
"Chromatic" <[EMAIL PROTECTED]> wrote:
> Advantages of inline tests:
> - close to the documentation
> - one place to update
> - harder for people to update docs without finding code
Plus, it gives us a mechanism to validate example-code
within documents
> Disadvantages:
> - doc tools must skip te
On Tuesday, November 12, 2002, at 10:47 AM, chromatic wrote:
On the whole, I prefer external tests. Brent's schema looks good.
OK, good enough for me. Without objection, let's do it that way.
MikeL
Michael Lazzaro:
# On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote:
# > Why use POD like this instead of a more atomic version of
# the standard
# > testing format used by Perl 5? We can use the directory
#
# Dunno, looking for a way where we can harness the authors for
# produci
On Tue, 12 Nov 2002 10:00:05 +, Michael Lazzaro wrote:
> On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote:
>> Why use POD like this instead of a more atomic version of the standard
>> testing format used by Perl 5? We can use the directory structure to
>> organize things. Since
On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote:
Why use POD like this instead of a more atomic version of the standard
testing format used by Perl 5? We can use the directory structure to
organize things. Since most tests are not worthy of inclusion in the
docs (do you really wan
On Tue, Nov 12, 2002 at 09:22:37AM -0800, Michael Lazzaro wrote:
> But I would imagine that in order to be helpful at all to p6i and QA,
> we need to make the tests paranoid, tedious, and as encompassing as
> possible. There may be implementation-specific tests (like memleaks,
> etc.) we can't
Michael Lazzaro:
# But I would imagine that in order to be helpful at all to p6i and QA,
# we need to make the tests paranoid, tedious, and as encompassing as
# possible. There may be implementation-specific tests (like memleaks,
# etc.) we can't help much with, but syntax and behavioral
# iss
14 matches
Mail list logo
