Test-Mapper/lib/Test/Mapper.pm

package Test::Mapper;

use strict;
use warnings;

#ABSTRACT: Map what parts of a codebase changing ought trigger acceptance tests

=head1 DESCRIPTION

The general tradition in perl unit testing is to map 'what to test' when a piece of code changes is simple:

    lib/Foo/Bar.pm -> t/lib-Foo-Bar.t (or t/lib-Foo/Bar.t)
    bin/baz -> t/bin-baz.t

Unfortunately things tend to get messy when you engage in more complicated testing, such as integration testing.
There, you have one-to-many relationships, but which can still be easily discerned programmatically via inspecting @INC.
That is unless you require() modules (or worse, read & eval/exec), in which case analysis via PPI must be brought to bear.
Still, most people solve that particular problem with the doctor's adage about "not doing things that hurt".

However, acceptance tests will blow out your build server's thinking budget quickly, being a many-to-many mapping.
To make things worse, much of the stack isn't necessarily in $LANGUAGE_OF_CHOICE.
Furthermore this is not something that can simply be avoided via careful structuring.

Knowing all this, what then shall we do?  Cheat.
AKA breaking an insoluble problem into many smaller soluble ones.
It is well within the ability of a test author to discern the route via which an acceptance test accesses a feature.
Indeed this is necessarily so.

As such if we structure our mapping from this perspective life becomes quickly simplified.
Taking as an example an average web application, we can imagine a mapping like:

    t/acceptance/DoFoobarFeature.t -> GET /ez/bez, POST /huth/buth, ...

And every single so loaded "endpoint" necessarily has a number of resources loaded.
It is well within the realm of possibility to hit these endpoints with L<Playwright>, grab a HttpARchive and map that to the relevant source files in the repo.

Similarly one can (in most cases) do the same thing with normal applications via C<ldd>, C<strace> and so forth.

=cut