Achievements

Testing Coverage

At the 2013 Perl QA Hackathon in Lancaster, England, testing coverage-related issues were handled by several participants, including the following:

Paul Johnson (pjcj)
Jim Keenan (kid51)
Abe Timmerman (abeltje)
Dinis Rebolo (drebolo)

... with remote assistance from Thomas Klausner (domm). The work had two major focuses:

1. cpancover: Improving reporting of testing coverage data on major CPAN modules, expanding on pjcj's cpancover.com.

2. perl5cover: Creating a mechanism to run coverage analysis over the C source code and Perl libraries in the Perl 5 core distribution and to make that analysis available.

cpancover

The purpose of the hackathon's work with respect to cpancover was to integrate cpancover with metacpan -- specifically, to place a link on a distribution's metacpan page pointing to the appropriate page in cpancover.

perl5cover

perl5cover will have two major aspects: one centralized, one distributed.

First, a centralized server will run a coverage report on the Perl 5 core distribution shortly after each release of a major (5.18.0) or minor (5.17.11) version of Perl. The coverage will use 'gcov' to report on the Perl 5 source code written in C and Devel::Cover-based tools for the Perl libraries (.pm files) which ship with the core distribution. At any point in time, a limited number of recent releases of major and minor versions will be displayed as web pages. However, plain-text versions of the coverage summaries will be retained indefinitely and be available for download.

Second, we will make available, probably in the form of a CPAN module, instructions showing how to run a coverage analysis on the core distribution at any commit.

If you are obsessed with how well covered the code in blead is at any moment in time, the second approach will be the better approach for you -- but you will have responsibility for maintaining the infrastructure.

If however, your objective is to identify inadequately tested parts of the Perl 5 core distribution and contribute appropriate, new tests to the test suite, then the first approach will be better. Our philosophy will be "KISS"; we'll try to get a basic, not-difficult-to-maintain infrastructure up soon. We'll worry about adding bells and whistles later.

This work will build on domm's App::ArchiveDevelCover, but we will probably end up creating one or more new CPAN distributions to achieve this. The hackathon saw a lot of work as well on the creation of a stand-alone program to run coverage of the core.

DBI::Test

DBI::Test is a new test suite controller and bundle to allow DBD's and other DBI related modules to test their spec compatibility. DBI::Test is to be run to test the DBI API from both sides (DBI and DBD).

Jens Rehsack (‎Sno‎), H.Merijn Brand (‎Tux‎), ribasushi +1 and joakim brainstormed and work on different parts. On the way back, Jens Rehsack (‎Sno‎) and Philippe Bruhat (‎BooK‎) discussed about Test::Database and decided to work together (merge some code and reponsibility from Test::Database and improve Test::Database to run in DBI::Test framework).

Jens Rehsack (‎Sno‎) will start working on the DBI::Mock part to allow DBI::Test can run self-tests without having DBI installed. Additionally, he's working on the setup and test population task in DBI::Test.

joakim works on the test modules from common basic ones up to complex ones later, when an initial setup is running. ribasushi +1 will function as primary mentor for Joakim's work while Jens Rehsack (‎Sno‎) is co-mentor.

H.Merijn Brand (‎Tux‎) doesn't do technical work in DBI::Test to keep a clear eye from DBI spec/API perspective.

The team will try to get as many DBD authors involved as possible and deal with feedback as soon as possible in order not to divert into a module that won't be used. We hope that this effort will show deficiencies on both ends.

Perl5 toolchain consensus

Each day a brainstorming meeting for 2-4 hours to discuss toolchain issues and find a community consensus for them.

Day one was for the build process:

Day two has been used to discuss meta spec:

On the third day testing issues (during the Perl module build process) were discussed:

For example, automation will be split into 3 environment variables instead of one: AUTOMATIC_TESTING is reduced to it's initial meaning (this is a test bot), newly introduced are NON_INTERACTIVE (entire build process is done by a bot, all prompted questions must use default answer) and EXTENDED_TESTING (user/bot/smoke tester) wants extended tests being done (extended tests are not intended to replace AUTHOR_TESTING or RELEASE_TESTING and should not increase requirements).

Installed module testing was discussed a long way with a lot of proposals to the author team. Everybody is excited about that approach.

New releases due vis-a-vis cooperation

...

Perl 5+6 CPAN cooperation

A long discussion on Sunday about a Perl6 CPAN results in many agreements. The first thing everybody agreed on, that Perl6 (authors, module authors and users) needs the same CPAN access as Perl5 ones. Technical details are open, but a fair way for now is uploading Perl5 modules and Perl6 modules into different subdirectories of the author home.

Further everyone agreed, that Perl is a language family whereby Perl5 and Perl6 are sisters

Test::Smoke

This project for CORE smoking had some patches integrated that were lingered from several sources from over the past year. We also fixed (we hope) a double-encoding bug that sends logfiles as garbage and integrated and tested new smoke ways to test smoke-me branches from git. All related projects have moved from svn to github by Abe Timmerman (‎abeltje‎).

version 6 saved on 15/04/13 11:25 by H.Merijn Brand (‎Tux‎)

Home | Tags | Recent changes | History