Advanced

Advanced Preloading



Advanced preloading occurs whenever you preload a module that subclasses Test2::Harness::Preload.

Advanced preload modules have several hooks that are covered in this section.

pre_fork

$class->pre_fork($job)



This hook is called just before yath forks to run your test.


The argument to this hook is the Test2::Harness::Job object, from which you can get things like the filename, directives, etc.

post_fork

$class->post_fork($job)



This hook is called just after yath forks to run your test.

Note that this occurs BEFORE some state cleanup such as fixing $0 and rewinding DATA handles is done.


The argument to this hook is the Test2::Harness::Job object, from which you can get things like the filename, directives, etc.

pre_launch

$class->pre_launch($job)



This hook is called just after yath finishes reseting the state such as $0 and DATA handles.

The very next thing after this hook returns is the use of goto::file to jump into the test file.

preload

$class->preload(\%do_not_load, $job_count)



This hook gives you a chance to do additional custom preloading.

This is very useful if you have a very long list of modules to preload.

The first argument is a hashref of blacklisted modules you should skip (if possible). This list is built based on inotify changes that have been observed in previous iterations.

The second argument is the number of jobs that will be run. This is useful if you want to avoid preloading eveything when only a single test file will be run.

stages

@list = $class->stages()

If your codebase is sufficiently complex you may want to create multiple preload stages.

Preload stages are different groups of preloads, often built on top of previous stages.

As an example, at ZipRecruiter we have stages like this:

CPAN
CPAN modules are loaded, but no internal code is
base
Our basic modules are loaded, this is built on top of the CPAN preloads
app1
One of our apps is preloaded on top of base
app2
Another app is preloaded on top of base.
Note that app1 and app2 are both built on top of base, and do not inherit preloads from eachother, the next page explains how!
fork_stages

@list = $class->fork_stages()



This hook allows you to specify that yath should fork before initializing the listed stages, which means nothing else will inherit from them.

Note that this all works for persist mode as well, each stage will have its own process all set to go!

future

How will this change going forward?



The way this preload system grew was fairly organic to solve a problem at ZipRecruiter.

For backcompat none of these hooks should change very much.

Moving forward there may be a new system that lets you define your preloads as a data structure (DSL?) that allows smarter inheritence, and requires less work from you.