To answer the questions for 03-revision.t:
James Keenan wrote:
1. Can you say a bit more about the context in which you ran this
test? 'make test'? 'prove t/postconfigure/*.t'? In particular, did
you run it *before* running Configure.pl or *afterwards*?
I ran Configure.pl a while ago (with several intervening runs of 'make'
and 'make test'), ran 'svn update', 'make', and 'make test'.
I don't run Configure.pl every time I update the repository. That
regenerates the Makefile, and so recompiles all of Parrot. I rarely need
to go that far.
2. If you do 'make clean', then 'svn update', then re-run the test, do
you still get the error?
That fixes the error. Until the next time I run 'svn update' and rerun
the test.
3. This test was tricky, and, in the course of developing it, I got
this same error several times. The trickiness arises from the fact that
the underlying code being tested, lib/Parrot/Revision.pm, has the name
of a file in the Parrot distribution hard-coded into its major subroutine:
sub __get_revision {
return 0 unless ( -e 'DEVELOPING' );
...
}
In my never-ending quest for complete code coverage, I had to devise a
way to test both branches in that return statement, i.e., test under
circumstances in which 'DEVELOPING' both does and -- here's the tricky
part -- does not exist. The only way I could do the latter was to copy
the relevant files into a temporary directory and, for certain tests,
not copy 'DEVELOPING' along with them. It's very hackish, but it did
enable me to get to full coverage of that statement.
Could you take a step back and explain what you're testing? At first
glance, I don't see why we would test the revision number. Just to be
sure that Parrot::Revision got some value during the configure process?
Allison
