Test-Simple Release-Candidates

This is an update to the ongoing efforts to update Test-Builder. At this point the updates have been merged into blead, that means the new Test-Simple will be part of perl-5.22, barring any significant reasons to remove it. This post is to provide details you should probably know.

The changes have entered the release-candidate stage. The plan at the moment is to go stable if we have an entire blead-cycle without any significant changes needed. What constitutes a significant change? This is a grey area, obviously documentation, version number, and error message typo fixes are not significant. Logic changes on the other hand can be, at the moment I am relying on discussion with the toolchain-gang and the perl-qa group to make this call.

At the moment I am relying on bug reports (see here) to find things that are broken. When something is broken I evaluate why it is broken, and decide if the breakage requires a Test-Simple patch, or a patch to the broken module. I provide my opinion, then discuss in #toolchain and #perl-qa on irc.perl.org. If the irc channels disagree with me I will default to the consensus, not to my own opinion.

How do I decide which module needs a patch? In general I follow these guidelines:

  • I will support any proper use of public methods in Test::Builder, Test::Simple and Test::More
  • I will not remove any public API methods/functions unless it can be clearly proven that nobody uses them
  • I will support monkeypatching of Test::Builder methods when possible, this includes: ok(), diag(), done_testing(), note()
  • I will support $Test::Builder::Level, and any code that uses it PROPERLY
  • I will not support monkeypatching private (underscored) methods.
  • I will not support use of private (underscored) methods that have been removed, unless there is a very good reason
  • I cannot support code that relies on replacing the Test::Builder singleton
  • I cannot support code that improperly sets $Test::Builder::Level
  • I cannot support code that directly accesses hash-elements in the Test::Builder singleton, many of these keys are now gone
  • I will try to convince the author to patch their code if it is an easy fix to the module, but a complicated one in Test::Builder, unless the issue is likely to effect other distributions

One of the fundamental changes under the hood is that the Test::Builder
singleton is no longer the central authority. This decision was made with
much hesitation. The fact is most issues and fragile complexity that I
encountered when people would try to extend Test::Builder were caused by the
singleton model. For an example look at how subtest are implemented in the
current Test-Simple stable version.

The new model moves only the bare minimum necessary for synchronization to a
semi-singleton (actually a singleton stack). Everything that can be done
without being inside a singleton is done independently. Test::Builder, and its
singleton, are now simply compatibility wrappers around the new model.

I have been working very hard to not break things. At this point there are no new features or refactors in the works or planned before the alphas go stable. All my work currently is devoted to stabilizing the alphas, and fixing anything that breaks. Whenever a broken module is reported to me I handle it as fast as I can.

I urge everyone to check their distributions, Specially if they are test related. If you find something I have broken please report it. If you want to look deeper and see why/how it was broken that would be appreciated, but not necessary. I will do anything within reason to fix the module, either by updating Test-Simple, or by helping to fix the broken module. My help to fix the module may be pointers, or even a patch if I can write on easily enough. I will also always try to make it so that the module works in both the old Test-Simple dists, and the new.

You can find the latest alpha on metacpan here


How do alphas reach rc wuithout going through beta? This will go well.


Simple terminology issue. On cpan you can release a dist as either indexed (stable/normal) or unindexed (usually denoted via an underscore and a number at the end of the dist version.) I had always seen people call these unindexed dists alphas. I had assumed that was simply the term for it on cpan. I always thought it was funny that there was alpha, but no other designation.

Your comment prompted me to take a look and ask around. Turns out un-indexed are not simply called alphas, which makes more sense. Mistake on my part, I will update my post to change the terminology, and I will no longer call them alphas.

Awesome work! Thanks for plowing thru all of this for us.

Leave a comment

About Chad 'Exodist' Granum

user-pic I write solutions to make things easier.