Michael Scott <[EMAIL PROTECTED]> writes: > On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels > wrote: > > > > Michael Scott <[EMAIL PROTECTED]> writes: > > > >> Here are some tests for the io.h API that should go in t/src/io.t. > > > > Ah yes. I know I submitted one too. I thought it got committed a long > > time ago but maybe it wasn't. I will try to merge it with your tests > > and commit a change. > > > > In one test you include "../io/io_private.h". I'm not sure if it's a > > good idea to test implementation details. On one side its better to > > test as many as you can, on the other side mainly the public API > > should be tested, the implementation should just work. > > I'm just including io_private.h to get the correct flags to test the > return values of PIO_parse_open_flags() which is in the public API.
Maybe PIO_parse_open_flags should also get moved to io_private.h. The private/public split of the io subsystem is far from complete. In fact io is the first subsystem that even tries to do so. > I agree there are limits to what should be tested, but what embarked > me on the tests in src/io.t was the failure of test 6 in pmc/io.t. I > tried to fix it, but because there were no src/io.t tests I couldn't > be sure whether the problem lay in the io.ops code or the io/* code. > > > Needless to say, once I'd written src/io.t, I got sidetracked into the > need for string C code tests, and never got back to pmc/io.t. > > > It seems to me that there are at various levels of "public" in Parrot, > and each one should be tested. Furthermore, the more tightly the > testing is done at the lowest level, the more confident we can be > about the higher level test results. Ok you convinced me, we need to test private implementation details. But this tests should be cleanly flagged as such. > PIO_parse_open_flags() is, I think, a good case in point. It makes > sense to throw a bunch of invalid values at it in src/io.t, and then > assume that it works in pmc/io.t. > > > BTW those src/io.t tests should be rewritten to use the scheme Leo > uses in the 3rd test in src/basic.t. I proposed a patch to simplify > this in "[PATCH] C code test header" which if you could get into CVS > I'd be grateful as my string tests will rely on it. The whole c_output_is() tests are more or less a hack. Ideally there would be C-markos like OK(val, name), DIAG(text), IS(this, that, name), etc. and be able to check individual c-statements without recompiling and running a new file each time. bye boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
