On 2011.1.6 10:08 PM, Jens Rehsack wrote:
> That's only one step - I want the line numbers of the test, and the test is
> currently written as an hash-entry in a test-list.
By "test" do you mean "where the entry is defined in the hash"? Like, for
example...
#line 1
my %tests = (
have => "want",
this => "that",
up => "down",
);
for my $have (keys %tests) {
is func($have), $tests{$have}, "func($have)";
}
If you want to test for "this" to report that it failed on line 3, inside the
definition of %tests, that's just not possible in Perl. In this case I would
recommend using a name for each test definition and outputting that either in
the test name or, if there's multiple asserts for the same definition, use
note() at the start to indicate which is running.
> Probably it's wiser to create an own "sql_test" sub which contains the code
> from the test loop (see t/06virtual.t for an example).
Yes, that would be the way to go. Incrementing $Test::Builder::Level will
make Test::Builder report further up the stack. If you wrap a bunch of tests
in a function called sql_test() and you want the tests to report where
sql_test() is called, just increment $Level.
>> Also, your 1.31_001 alpha is actually $VERSION 1.32. If this was
>> intentional,
>> I would recommend against prematurely increasing the actual $VERSION. It
>> will
>> cause confusion with the real release, not everything respects the
>> distribution version (ie. what's on the tarball), and it's odd to unpack
>> Foo-1.23_01.tar.gz and get Foo-1.24. Now that 1.32 is confused, I would
>> recommend you skip 1.32 and the next alphas be 1.32_0x. Then the final
>> version be 1.33.
>
> Yes, maybe - but this might confuse others ...
> I had chosen this kind of file renaming according to xdg's blog entry
> "version numbers should be boring".
That article talks about X.Y_Z alpha versions. I think you misunderstood it.
They're fine. There is a recommendation against using alpha versions with
version.pm, but regular string $VERSION alpha is fine. Look at the conclusion
where he says to use the $VERSION + eval trick which is specifically in case
of alpha versions.
Boring is when Foo-Bar-XYZ.tar.gz contains Foo-Bar-XYZ and is version XYZ.
"Exciting" is when Foo-Bar-XYZ.tar.gz contains Foo-Bar-ABC and is version ABC.
>> Finally, the disparity between the tarball name and the directory indicates
>> that you're not using "make dist" to create your tarball. This risks picking
>> up things ignored by your MANIFEST.SKIP.
>
> No - I did a "make test && mv $a $b"
I would recommend "make manifest && make disttest && make dist" being sure to
keep your MANIFEST.SKIP up to date.
"make manifest" has the advantage of always being sure your release MANIFEST
isn't out of date.
"make disttest" the advantage of running the tests in a clean distribution
directory based on MANIFEST, so it's sure to be clean of all artifacts and
other whatnot lying around in your work directory. It's a good simulation of
how it will be run when shipped.
"make dist" also has the advantage of ensuring your distribution doesn't have
any artifacts in it and your tarball name and version matches your distribution.
That will give you regular, faster releases with less human mistakes.
--
170. Not allowed to "defect" to OPFOR during training missions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
