in reply to TAP question

You could have an overall .t file that runs each other test file with TAP::Harness and outputs an ok or a not ok with diagnostic info for each existing .t file.

But wouldn't it be better to allow for more than one .t file per suite? If you aren't already aware, there have been dramatic improvements in the flexibility of Test-Harness since perl 5.8.8 that may be of assistance to you.

Much discussion of testing takes place on the perl-qa list. You may want to check it out if you don't find the answers you need here.

Replies are listed 'Best First'.
Re^2: TAP question
by amarquis (Curate) on Feb 26, 2008 at 06:42 UTC

    I believe that s/he already has multiple .t files per suite, but wants a single TAP output from each set. Or, something to take the TAP output from each .t files, and turn it into a single TAP output.

    I'd take a look at TAP::Parser, which at least seems like it would help you roll your own solution if there wasn't a prebuilt module.

      I believe that s/he already has multiple .t files per suite, but wants a single TAP output from each set. Or, something to take the TAP output from each .t files, and turn it into a single TAP output.
      Yes, I understood that much. But the OP wants single TAP output because "I'm building a test framework that tests a number of different components, each with it's own suite of test cases".

      It doesn't seem like it's going to be substantially easier to coerce multiple TAP streams into one and then feed that to the test framework than to just make the test framework support multiple tests per suite in the first place. Probably the contrary, in fact.

Re^2: TAP question
by emalossi (Novice) on Feb 26, 2008 at 19:51 UTC
    Interesting idea. This could work. I can't make any mods to the existing .t files to make them provide a return value since I don't own them, but I could manually parse the output stream looking for "not ok", and if found, trigger a failure for the entire file. Thanks!
      I wasn't suggesting manually parsing them. If you just look for "not ok", for instance, you lose the ability to have TODO tests. I was suggesting having a single .t file that uses TAP::Harness to run the existing .t files and give a per-file ok or not ok result (that your outer framework interprets).
        Hmm I guess I'm confused then. The only way I've generated TAP in the past is by using Test:More either ok() or is() or something to test values. Given that the existing .t files don't return predictable values, the only thing I could test for would be the TAP output that the test cases contained within are producing.

        How would running all of the .t files using TAP::Harness from within a .t file, rather than from the main script give me any different output?

        The only way I can imagine getting a different output would be to run it something like this:

        set SDTOUT to a file for each .t file run .t parse output file for each line do either: is(1,1,testcasename) or is(1,0,testcasename) next file

        What is is that you're suggesting?