This talk will help you get started arranging your tests into modules. We'll cover setting up a simple TAP::Harness to run your tests. Then we'll see how Plus Three has used Test::Class to divide up and reuse code in our test suite.
Separating tests out from a large .t file into modules and subroutines has helped me confirm more quickly that a code change has not introduced a regression. Developers save time by only running the relevant subset of tests before committing a change to the code or a change to the tests themselves.
I'll offer a few tips on checking preconditions in your testing environment (e.g. is a daemon running, is an external service url reachable) and
either bailing out gracefully or trying to remedy the situation.
You can ease into this modularization adventure. With Test::Class your shinier new tests can work right beside the venerable dustier ones letting you rework them as they need it.
grab a list of .t files then create a TAP::Harness object now have the harness run the tests
the harness object can take arguments in new(). can try with verbose -- ok for every passing test. The merge option on new merges STDOUT and STDERR -- this is most useful when using TAP::Harness::Archive -- you know, for submitting to a Smolder server.
We do some setup in our harness before we get to running any test code. If ARCOS_ROOT isn't set, calculate it from harness path. We modify the PERL5LIB to add our application lib. Try loading Arcos module and bail if cannot.
We do some setup in our harness before we get to running any test code. If ARCOS_ROOT isn't set, calculate it from harness path. We modify the PERL5LIB to add our application lib. Try loading Arcos module and bail if cannot.
We do some setup in our harness before we get to running any test code. If ARCOS_ROOT isn't set, calculate it from harness path. We modify the PERL5LIB to add our application lib. Try loading Arcos module and bail if cannot.
Go ahead and add more BEGIN blocks Our code also needs pointed to an instance (any instance) within our configuration. Pick the first one if none is already set.
Arcos sets a version string. This Arcos Script will see if we're running as the right system user and become them with calls to setuid() and setgid() We do more here, but that's beyond the scope of this talk.
You've all seen Getopt::Long's GetOptions() We use it to pull in command line parameters to our harness. There are a handful more than are listed here database passwords a test_pollution flag
“ try” -- Colorized results depends on terminal support. if your tests can be run in parallel without interfering with one another, TAP::Harness can handle it.
Spread is only part of what island_mode.t exercises, so skip instead of skip_all
Here is a sample showing the individual test assertions you're used to seeing : ok, like, etc. We capture the stdout and stderr with a backticks execute and check the results. We use some of the data to pull a job from the database, retrieve the associated contribution, and check its contact information.
open_handler.t tests that we properly handle the image requests from end users opening emails. no_plan is still a plan. If apache is not running, none of this test is going to be useful. so we skip_all.
.
.
use base 'Test::Class'; json_success and json_failure are calls to json_contains('success') and json_lacks('success) respectively.
Here we can see the common definition of methods that will be shared by the children. x_create_form has the Test(startup) attribute, so it will be run before the regular test methods. The 3 parameter notes how many tests are within that method. The form_db_class() method is used in the x_create_form() call to setup the form before the tests begin. Here it is empty string, the children must override with a proper value. ContactOfficial forms need some additional elements, but Register forms do not.
Because it is inherited, the tc_startup method can be completely overridden, or merely augmented if the call to SUPER is included.
This script performs a couple checks before calling runtests. These are common across many of our tests and are defined in Arcos::Test. needs_running_apache checks if apache is running and attempts to start it if not. If apache cannot be started, the test would skip with the following code: Test::More::plan(skip_all => 'Could not start Arcos Apache/mod_perl server');
We also stop our Arcos job queue daemon for this test. We want to be able to inspect jobs as they're inserted into the queue, before they're processed.
Now we restart the queue so that it functions normally for other tests.
While developing tests it may be convenient to go ahead and skip particular test methods. Calls to return() will be interpreted as a skip. A string can be passed to provide a reason for skipping the rest of that method.
In run scripts it's often best to just skip the whole module worth of tests if some conditions do not exist. ContributionTestMode is imported from Arcos::Conf Do add descriptive instructions to your messages, if you're doing something unusual in part of your tests.
This environment variable can save you time while developing your tests. Its value restricts which of the subroutines with the Test attribute are run. The startup and shutdown subroutines are still going to be called. In a large file with many tests, this can help you iterate quickly when making and checking modifications to specific subroutines.
You can treat it as a string, but it is a regex and can perform more complicated matching. Here we're running any Test methods that either start with a_ or with b_ in their names. (possibly show how often I use it: “ history | grep TEST_METHOD”)
Many of our report modules have a common ancestor in Arcos::Report::SiteEvents These reports all provide Listing of forms, Downloading CSV data, It was only natural to use inheritance to gain some reuse in the testing code too.
We don't do much with marking tests as TODO in our suite. Here is how you can.
Lots of our tests are interacting with the web interface of Arcos. Often it is nice to get a failing test to stop for a bit before cleaning up and removing all of the evidence during shutdown. I find myself adding this little fragment all the time. Put the pause code in your shutdown method if you want to be able to use it with any routine you're putting into TEST_METHOD. Examples: * a new column is added to a listing screen. * the test isn't including a timestamp into the form names, and is choking because the database hasn't been cleared between runs.
Our run scripts make use of some reused routines in Arcos::Test. needs_run_daily is one of those cases. Be nice and put the instructions into the skip messages for running the conditional parts of your unusual tests. The external vendor had a limitation on the number of requests they could receive before an over-limit error was returned. We didn't want these tests running on each developers laptops even once daily. We wanted these tests to run a maximum of once daily in our automated test environment.
My resource for learning this material was an existing codebase. Hopefully these other resources will be helpful to you.