t/include/ holds only one test file
will at coleda.com
Thu Dec 16 13:59:04 UTC 2010
On Thu, Dec 16, 2010 at 8:44 AM, Peter Lobsinger <plobsing at gmail.com> wrote:
> On Wed, Dec 15, 2010 at 7:13 PM, James E Keenan <jkeen at verizon.net> wrote:
>> $ ll t/include/
>> total 1
>> -rw-r--r-- 1 jimk jimk 760 Dec 14 20:30 fp_equality.t
>> This directory in our repository holds a single test file. From the
>> t/include/fp_equality.t - Test runtime/parrot/include/fp_equality.pasm
>> DESCRIPTION: Tests fp_* functions.
>> Could this file be moved to another directory? Do we expect to have to
>> write tests for other files under runtime/parrot/include/?
> There are only 2 other files in that directory which are not
> automatically generated by h2inc:
> * test_more.pir - straightforward and already gets a heavy workout
> from our test suite. no test required.
> * hllmacros.pir - contains macros for emulating HLL constructs in
> assembly. if I remember correctly, these are known to be buggy, and
> their use is ill-advised. why hasn't this been removed yet?
> Neither of these two files are likely to get tests.
$ ack -ai hllmacros t
$ prove t/library/hllmacros.t
t/library/hllmacros.t .. ok
All tests successful.
Files=1, Tests=17, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.02 cusr
0.03 csys = 0.09 CPU)
These macros are tested, and are used extensively in partcl.
$ prove t/library/test_more.t
t/library/test_more.t .. ok
All tests successful.
Files=1, Tests=117, 1 wallclock secs ( 0.04 usr 0.01 sys + 0.12
cusr 0.04 csys = 0.21 CPU)
> This directory is exclusively for files using assembly code textual
> inclusion as a loading mechanism. Among parrot devs, this has fallen
> out of favour as a means of separating abstractions out into files. We
> are unlikely to add more files that use textual inclusion at the
> assembly level as their method of loading.
> Recap: new tests for existing files unlikely & new files unlikely.
> therefore, new test files unlikely.
>> I would like to know because 't/include/' is currently *not* include under
>> either 'make test' or 'make fulltest' -- which means it's not regularly
>> being run at all.
> Well that's a problem. These tests prove (or should prove) that the
> floating point comparison macros (which are/should be used pervasively
> through our test suite) are sane. This sanity is critical to the
> testing of other components of parrot.
>> Thank you very much.
Will "Coke" Coleda
More information about the parrot-dev