Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous.

Additional tests welcome

  • 1 Replies
  • 961 Views
*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 353
    • View Profile
Additional tests welcome
« January 31, 2017, 03:17:16 PM »
We can always use some more "t" tests, as well as internal (development) regression test buckets. Keep in mind that the "t" tests get run at installation, so let's not go overboard on those. Perhaps there can be a separate directory of "t" style tests that developers could run when they've made changes to the code, but don't really need to be run during installation. There could also be some tests that create a PDF to look at (unlike the "t" tests).  Automated validation is always preferable, but sometimes that just doesn't fit the situation. What do developers here think? I could add a "tests/" directory (sibling to "t/") for all sorts of miscellaneous tests.

Particularly when code is changed to address a specific bug, it's good to have a test or two that verifies that the bug has been squashed and has stayed squashed through later releases. There's nothing that screams "haphazard sloppy development" and poor version control more than old bugs coming back for no apparent reason!

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 353
    • View Profile
Re: Additional tests welcome
« Reply #1: March 30, 2017, 10:27:02 AM »
I'm thinking that some of the "t" tests are unnecessary and can come out. For example, it should be necessary only to test 1 or 2 predefined paper sizes, rather than all of them. If the code works for 1 or 2, it should work for all of them. There have been complaints about there being just too many tests, slowing down installation.

By the way, there is a Windows batch file t-tests.bat for running all the "t" tests. It's fairly crude right now, but does the job. Something fancier that is easier to use might be in order, especially if it is cross-platform. It might even be written in Perl, but be careful not to use any PDF::API2 functionality (which you're trying to test). Running "t" tests is something most developers using PDF::API2 don't do, unless they're making changes to the PDF::API2 code itself, so fancy testing applications may not be worth putting all that much effort into.

Demo or tutorial samples, such as examples/Content.pl and examples/ContentText.pl, serve multiple purposes: additional testing beyond the "t" tests, samples for developers to use, and the basis for more complete documentation.