NAME
Fennec::Manual - Manual for Fennec.
DESCRIPTION
Fennec provides a solid base that is highly extendable. It allows for the writing of custom nestable workflows (like RSPEC), Custom Asserts (like Test::Exception), Custom output handlers (Alternatives to TAP), Custom file types, and custom result passing (collectors). In Fennec all test files are objects. Fennec also solves the forking problem, thats it, forking just plain works.
THE QUICK AND DIRTY FENNEC PITCH
Fennec is not just good for writing new tools, it comes with everything the common Test::Builder tools provide and more. Here is a list of things Fennec does for you that not everything else thinks of:
Test grouping
tests 'Group A' => sub {
ok( 1, "1 is true!" );
ok( 2, "2 is too!" );
};
Usually you group similar tests together anyway, why not isolate them? Doing this also allows you to run groups in parallel, or run only the group on which you are currently working.
Handy workflows to make testing tasks easier
RSPEC like:
describe 'Workflow' => sub {
my $self = shift;
before_each { $self->do_something };
it { ok( 1, "1 is true!" ) };
it { ok( 2, "2 is true!" ) };
after_each { $self->do_something_else };
};
Case:
cases {
my $var;
case { $var = 1 };
case { $var = 2 };
tests { ok( $var, "var is true" ) };
tests { ok( is_prime($var), "var is prime" )};
}
These workflows come with Fennec, they sure do make life easier! It is also fairly easy to use Fennecs framework to write custom workflows.
Running subsets of tests
These commands can be used to run a subset of tests within a specified test file:
$ FENNEC_ITEM="item name" FENNEC_FILE="Filename" prove -I lib -v t/Fennec.t
$ FENNEC_ITEM="line number" FENNEC_FILE="Filename" prove -I lib -v t/Fennec.t
Thats right, you can specify a group or workflow name, or even a line number! Only that workflow ro group will be run, no waiting around for other tests to get at what you care about. Line number can be any line number across which the workflow or group is defined.
Parallelizing test groups within test files
See 'Test grouping'. Each group can be run in parrallel.
Object oriented test files
All test groups and workflows are blessed methods. Your test file defines a package, which is initialized. All groups and workflows are run as methods on the same test object (May be in different processes).
Command line tools to make life easier
Create t/Fennec.t with a good default config:
$ cd project_dir
$ fennec_init
Create scaffold tests for every module in /lib
$ cd project_dir
$ fennec_scaffold
Run a specific test file:
$ cd project_dir
$ fennec_prove t/MyModule.pm - [prove options]
Run a specific test group by line number or name:
$ cd project_dir
$ fennec_prove t/MyModule.pm "My Group" [prove options]
Test Randomization
Test groups are run in random order by default. You can easily disable randomization if needed on a global or per test basis. Fennec prints out its random seed so you can reproduce the order if necessary.
USAGE DOCUMENTATION
This covers basic usage of Fennec if you just want to start writing tests.
- Tests
-
Fennec::Manual::Tests - Examples of different fennec tools.
- Fennec Based Test Suite
-
Fennec::Manual::TestSuite - How to create a Fennec based test suite.
- Standalone
-
Fennec::Manual::Standalone - Write fennec tests that stand on their own.
- Command Line Tools
-
Fennec::Manual::CommandLine - Command line tools provided by Fennec.
- Vim tools
-
Fennec::Manual::Vim - Vim tools and rc files provided with the dist.
- Running Fennec
-
Fennec::Manual::Running - How to run individual Fennec test files, or zeroing in on specific testsets.
ASSERTIONS (TESTERS)
Assertions are the actuals testers. ok(), is(), etc. are all assertions. A testset is comprised of 0 or more such assertions. Each assertion sends a result to the handler(s).
Each testset itself generates an additional result when completed. Testset results are true if the testset lived, false if it died. This allows the use of 'traditional' assertions which do nothing if successful, but die upon failure. Most Fennec assertions work like Test::Builder based tools, they do not die upon failure.
- Writing Assertion Libraries
-
Fennec::Manual::Assertions - Guide to writing custom assertion libraries
- Using Test::Builder Based Tools
-
Many Test::Builder tools will work as expected within Fennec, however some may require, or can be improved by wrapping them into Fennec.
Fennec::Manual::TBAssertions - Using Test::Builder based tools with Fennec.
- Core Assertion Libraries
-
Many of these were named to reflect which Test::XXX module they mimic. All Core assertion libraries are imported by default.
Fennec::Assert::Core::Simple - ok(), use_ok, and similar assertions.
Fennec::Assert::Core::More - Assertions for comparing data and structures.
Fennec::Assert::Core::Exception - Assertions for testing exceptions.
Fennec::Assert::Core::Warn - Assertions for testing warnings.
Fennec::Assert::Core::Anonclass - Create anonymous objects based on specifications, created objetcs will have assertions as methods ($obj->is(), $obj->can_ok(), etc...)
- TBCore Assertion Libraries
-
If you prefer to use the well tested and commonly used Test::Builder based tools instead of the Fennec implementations then Fennec::Assert::TBCore is here to serve you.
Fennec::Assert::TBCore::Simple - Test::Simple
Fennec::Assert::TBCore::More - Test::More
WORKFLOWS
Workflows are ways to seperate, group, and structure tests. A good example of a test workflow would be Ruby's RSPEC. Fennec has an implementation of the SPEC workflow in addition to others.
- Writing Custom Workflows
- Core workflows
-
Fennec::Workflow::Module - Workflow that lets you define testsets and setup/teardown as methods on your test object.
Fennec::Workflow::Spec - Implementation of the SPEC test workflow
Fennec::Workflow::Case - A workflow that lets you run testsets under multiple cases.
RESULT HANDLERS
A Result handler is a single object in the root process to which all results are passed as they are collected. The handler is responsible for doing something useful with them. The default handler is the TAP handler which provides TAP output. Multiple handlers can be used at a time, and they can do anything they want with the results.
- Writing Custom Handlers
- Core Handlers
-
Fennec::Handler::TAP - Produces TAP output for result objects.
COLLECTORS
Fennec has test parallelization, this means forking into multiple processes. Collectors are responsible for funneling all results to the parent process where they are then sent to handlers. A collector needs to implement 2 things, a writer method that takes results as input, and a cull method which collects the results.
- Writing Custom Collectors
- Core Collectors
-
Fennec::Collectors::Files - The default, writes results as files in _results, then in the parent process these files are read.
Fennec::Collectors::Interceptor - Used by Fennec::Assert::Interceptor in order to capture results instead of sending them to the handlers, this is not a true collector, but a perfectly valid use of the framework.
FILE TYPES
When Fennec was first conceptualized there was mention of TestML http://www.testml.org, as well I decided it would be useful to be able to customise how test files are found/loaded. This led me to make loading test files a pluggable system. Using custom file loaders you can potentially use any type of test files you would like.
*There is not currently a TestML plugin, sorry.
- Writing Custom File Types
- Core File Loaders
-
Fennec::FileLoader::Module - The default, looks for .pm files in t/ and loads them as standard perl modules.
Fennec::FileLoader::Standalone - Used in standalone tests.
OTHER DOCUMENTATION
- Mission
-
Fennec::Manual::Mission - Why does Fennec exist?
AUTHORS
Chad Granum exodist7@gmail.com
COPYRIGHT
Copyright (C) 2010 Chad Granum
Fennec is free software; Standard perl licence.
Fennec is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the license for more details.