On Oct 31, 2007, at 8:16 AM, James E Keenan wrote:
On Oct 30, 2007, at 11:51 PM, chromatic via RT wrote:
On Monday 29 October 2007 20:02:52 James Keenan via RT wrote:
Tonight I again had failures in 3 files in t/tools/ops2pmutils/.
I again had to implement Coke's suggestion and run: make -f
tools/dev/ops_renum.mak
This renumbered the ops in src/ops/ops.num. This could have been
avoided if make buildtools_tests had been run.
If actual behavior depends on this utility being run, it should be
in the
Makefile. If the behavior doesn't really matter, we should
rethink the
purpose of the tests.
When I was writing the tests of the build tools last winter, my
assignment (at least as I interpreted it from particle) was: Test
all the Perl 5 code and, if it's not in a format that makes it
readily testable, get it there.
And so I did. But a tremendous amount of what happens in tools/
build/pmc2c.pl, ops2c.pl and ops2.pm.pl (the three scripts called
by make which were refactored into modules and unit tested)
reflects judgments about how Parrot's pmc and ops should be set up,
manipulated and transformed into C code. That was outside the
scope of my tests; it was what I took as given. The build tools
tests essentially say: "Make sure you don't break what we decided
was given."
So, if we decide to reformulate the behavior -- and do so in a
manner that is test-driven -- then we have no problem. We simply
write new code and tests, with the latter replacing some of my
tests. But if we decide to reformulate the behavior *without*
writing new tests, then I have a *big* problem with that.
Jim Keenan
I believe the issue here is that we probably need a test to make sure
that when someone adds/deletes/updates ops but doesn't renumber them,
it fails. I am unsure if this test is explicitly test for that, or if
it implicitly requires it, and therefore fails when it hasn't been done.
Also good would be a small doc in docs/ about "how to add/delete an
opcode" would be good, as then we have something we can point
committers to.
--
Will "Coke" Coleda
[EMAIL PROTECTED]
