Naah - you can just copy a file like I posted above into your xt/ (or t/) directory. If you put it in the t/ directory and name it (say) 99-changes.t, it will get run automatically whenever you run make test or prove -bl t/. If you put it into xt/, it will only get run when you run it explicitly, as author tests are not run by everybody. You need to remember to run those tests locally though - I always do that by always running prove -bl xt/ t/, but having a test that constantly fails is not great during development either.

You should skip that test if your VCS (e.g. git) is not (yet) clean.

Testing the Changes/ChangeLog is something you only want to do just before a release.

It is easy to built that skip into xt/99-changes.t. That is up to the OP. I'd use a module though:

$ cat xt/99-changelog.t
#!/usr/bin/perl

use strict;
use warnings;
use Test::More;

eval "use Test::CPAN::Changes";
plan skip_all => "Test::CPAN::Changes required for this test" if $@;

changes_file_ok ("ChangeLog");

done_testing;
[download]

And while at it, also add additional tests:

$ cat xt/50_manifest.t
#!/usr/bin/perl

use strict;
use warnings;
use Test::More;

eval "use Test::DistManifest";
plan skip_all => "Test::DistManifest required for testing MANIFEST" if
+ $@;
manifest_ok ();
done_testing;
[download]

$ cat xt/40_filenames.t
#!/usr/bin/perl

use strict;
use warnings;
use Test::More;

eval "use Test::Portability::Files";
plan skip_all => "1..0 # Test::Portability::Files required for these t
+ests\n" if $@;

BEGIN { $ENV{RELEASE_TESTING} = 1; }

options (use_file_find => 0, test_amiga_length => 1, test_mac_length =
+> 1);
run_tests ();
[download]

Of course you need pod checks too and when all that is done, dig into Test::Kwalitee to go next-level.

Good luck and kudo's for trying!

edit: I tracked my ChangeLog check:

sub check_changelog {
    # Check if the first date has been updated ...
    my @td = grep m/^Change(?:s|Log)$/i => glob "[Cc]*";
    unless (@td) {
        warn "No ChangeLog to check\n";
        return;
        }
    my %mnt = qw( jan 1 feb 2 mar 3 apr 4 may 5 jun 6 jul 7 aug 8 sep 
+9 oct 10 nov 11 dec 12 );
    open my $fh, "<", $td[0] or croak "$td[0]: $!\n";
    while (<$fh>) {
        s/\b([0-9]{4}) (?:[- ])
            ([0-9]{1,2}) (?:[- ])
            ([0-9]{1,2})\b/$3-$2-$1/x; # 2015-01-15 => 15-01-2015
        m/\b([0-9]{1,2}) (?:[- ])
            ([0-9]{1,2}|[ADFJMNOSadfjmnos][acekopu][abcgilnprtvy]) (?:
+[- ])
            ([0-9]{4})\b/x or next;
        my ($d, $m, $y) = ($1 + 0, ($mnt{lc $2} || $2) + 0, $3 + 0);
        printf STDERR "Most recent ChangeLog entry is dated %02d-%02d-
+%04d\n", $d, $m, $y;
        unless ($ENV{SKIP_CHANGELOG_DATE}) {
            my @t = localtime;
            my $D = Delta_Days ($y, $m , $d, $t[5] + 1900, $t[4] + 1, 
+$t[3]);
            $D < 0 and croak RED,    "Last entry in $td[0] is in the f
+uture!",               RESET, "\n";
            $D > 2 and croak RED,    "Last entry in $td[0] is not up t
+o date ($D days ago)", RESET, "\n";
            $D > 0 and warn  YELLOW, "Last entry in $td[0] is not toda
+y",                    RESET, "\n";
            }
        last;
        }
    close $fh;
    } # check_changelog
[download]

If you prefer dark themes or no colors at all, you probably want to alter the warning lines.

This check is based on English *only*. Even though I am Dutch, my log entries are English only.

@corion $ENV{SKIP_CHANGELOG_DATE} is set in the calling process if my git is not clean.


Enjoy, Have FUN! H.Merijn

Don't we then need to copy the test file into xt/ which is as easy to overlook as updating the change log?

You only need to copy/create the test file once. You need to update the change log on every release.

---

🦛

I wrote Dist::Mgr for this exact reason. It comes with a distmgr binary that does all the work.

It extends Module::Starter for distribution creation, and it automates everything else. Adds Github Actions workflow, adds CI and coverage badges, adds repository information. It has a 'release' feature which runs tests, ensures the MANIFEST is up to date, updates the Changes file automatically with the date and version, pushes to Github to run CI tests, then finally, if all is well, it pushes it onto the CPAN.

A 'cycle' feature bumps version number information, prepares the Changes file for the next version's changes etc.

I've been using it for a few years now. It's how I manage all of my Perl distributions.