A piggy bank of commands, fixes, succinct reviews, some mini articles and technical opinions from a (mostly) Perl developer.

Run only one subtest with Test::More

Apply this patch to Test/More.pm, version 1.302075:

807d806
<     return if exists $ENV{SUBTEST} && $ENV{SUBTEST} ne $_[0];

Here's that patch again, in unified format:

$ diff -u Test/More.pm{,.orig}
--- Test/More.pm      2017-07-27 13:23:56.000000000 +0100
+++ Test/More.pm.orig 2017-07-27 13:19:00.000000000 +0100
@@ -804,7 +804,6 @@

 sub subtest {
     my $tb = Test::More->builder;
+    return if exists $ENV{SUBTEST} && $ENV{SUBTEST} ne $_[0];
     return $tb->subtest(@_);
 }

Run the test like this:

SUBTEST="put name of subtest here" /usr/bin/prove -v test_file.t

Why it's important to merge upstream at the end of every sprint

The whole idea of agile/scrum is to regularly and frequently provide value to the business.

If you already deploy to production every few weeks, or tag your feature branch and deploy it to a Testing or Production environment for users or other stakeholders to see, then that's great! You probably don't need to merge to master or trunk in that case.

But say your release cycle is every two months so new features won't actually reach production for some time after being built. If you don't merge the sprint's work to master and don't deploy it anywhere, then it weakens all the good habits of agile working. Every sprint the developers will feel slightly less motivated to complete the work on time because it won't really matter, nothing is being done with the work. In this situation, merging to master is a proxy for deploying to production. But an even better proxy for deploying to production is: Deploying to an environment, preferably an environment of which the stakeholders have visibility.

If you don't like using master/trunk, then designate a common feature branch, release branch or any other kind of special branch to merge each set of changes to. The point is that branch should not be under direct control of the feature developer anymore. Any new changes require a new issue/branch to be created, reviewed and merged separately. It's psychologically cleaner.

There are many benefits to keeping branches small and merging upstream frequently:
  • The whole team gets to review the code, even (especially) people who haven't seen it yet
  • Smaller branches are easier for the team to review
  • Mistakes are caught earlier so less work is needed to rectify them
  • The new code can be more easily tested in continuous integration, which probably already runs off master
  • Reduces conflicts with the rest of the codebase
  • Makes it easier to work on new features in parallel (the alternative is using a common feature branch and sub-branches)
  • Keeps you honest by "publishing" your work, prevents feature creep, makes iterations clear, etc.
  • Makes it more efficient to work on and think about, you keep fewer things in your head because it's not all "up in the air"