Robert Rothenberg > CPAN-YACSmoke-0.03_07 > CPAN::YACSmoke::FAQ


Annotate this POD


New  9
Open  8
Stalled  2
View/Report Bugs


CPAN::YACSmoke::FAQ - YACSmoke Frequently Asked Questions


General Questions

YACSmoke does/does not ...

YACSmoke uses CPANPLUS::Backend to download, extract, and test packages and send out the reports. The advantage is that we don't have to re-write duplicate code. The disadvantage is that some of the bugs in CPANPLUS will affect CPAN::YACSmoke as well.

Test reports have my build directory location...

This is a CPANPLUS issue, not a YACSmoke issue. To change it, you need to change the extractdir and fetchdir locations in CPANPLUS. Open the shell and run the following commands:

  s conf extractdir /some/extract/dir
  s conf fetchdir /some/fetch/dir
  s save

Alternatively, you can update those settings in the cpansmoke.ini file, but that will only affect test reports sent out using YACSmoke, and not those from the CPANPLUS shell.

Module Authors

How can I tell if my module is being tested by YACSmoke?

Your module should check if the AUTOMATED_TESTING envornment variable is set:

  if ($ENV{AUTOMATED_TESTING}) { ... }
What if my module needs user input for testing?

There are several solutions:

  • Use an environment variable or cross-platform method of locating a configuration file that has the information you need.
  • Skip all tests that need this input if $ENV{AUTOMATED_TESTING} is set, and live with the fact that automated smoke tests for your module won't be thorough.
  • You can use a package such as Test::Expect to test automated interactive sessions. (Note that Test::Expect may not run on every platform, so you should skip the tests if it is not installed.)

    For Windows programs which use a graphical interface, there's also Win32::GuiTest.

  • Include sample data to test against if no user data is available.
Why should I care if your (explitive) OS doesn't have (feature)?

See perlport - Writing portable Perl.

How can I get YACSmoke to issue an NA report?

YACSmoke relies on CPANPLUS to determine that. Currently (CPANPLUS version 0.054) looks at the module name: if it begins with a platform name such as "Win32" or "Solaris", then it issues an "NA" (Not Applicable) report.

We are looking into ways to allow tests to issue NA results rather than relying on package names.

One suggestion from the Perl module-authors list is in the Makefile.PL and Build.PL to die with a reason:

  die "NA: $reason";

Note that current versions of CPANPLUS and YACSmoke do not yet recognize this.




syntax highlighting: