HTML::...:Tests(3pm)

✨ NAME ✨

okay bestie, so this page is HTML::Mason::Tests — straight out of the User Contributed Perl Documentation, section 3pm 💖 — and it is the test harness for testing Mason. That's literally the whole name. Iconic, concise, we love.

---

🌸 SYNOPSIS 🌸

here's the vibe, no notes:

use HTML::Mason::Tests;

my $group = HTML::Mason::Tests->new( name => 'name of group', description => 'tests something' );
$group->add_test( name => 'foo',
                  description => 'tests foo',
                  component => <<'EOF'
<%args>
$foo => 1
</%args>
<% $foo %>
EOF
                  expect => <<'EOF',
1
EOF
                );

$group->run;

---

💅 DESCRIPTION 💅

so the whole point of this module is to automate as much as possible of the Mason test suite, fr fr. It does all the annoying stuff for you: writes component files to disk, calls them, compares the actual results against the expected results, and more. And bestie, it also prints out genuinely useful info about test failures when you run it in verbose mode — check the ADDITIONAL RUN MODES section below for that tea 🫖.

It also makes sure that any given group of tests actually provides all the info needed to run them (test names, components and results, etc.). Like a bouncer at the club but for test data.

So now you have no excuse for writing new tests (and that goes double for me!). 😭

---

🎀 METHODS 🎀

🦋 new 🦋

takes these parameters, bestie:

• name (required) — the name of the entire group of tests.
• description (required) — what this group tests.
• pre_test_cleanup (optional, default=1) — if this is true (and it is, by default), the component root and data directory will be deleted both before and after running tests. so clean, so fresh 🧼

✨ add_support ✨

takes these parameters:

• path (required) — the path that other components will expect this component to be reachable at. All paths are prepended with the group name. So '/bar' as a support component in the 'foo' group's ultimate path would be '/foo/bar'. 👑
• component — text of the support component. This parameter must have a value unless the skip_component parameter is true.
• skip_component — if true, then the test harness will not write a component to disk for this test.

💖 add_test 💖

takes these parameters:

• name (required) — the name of this test.
• description (required) — what this test is testing.
• component (required) — text of the component.
• path (optional) — the path that this component should written to. As with support components, this path is prepended with the group's name. If no path is given, it uses call_path, if given, otherwise it uses the name parameter.
• call_path (optional) — the path that should be used to call the component. If none is given, it will be /<group name>/<test name>. If a value is given, it is still prepended by /<group name>/.
• call_args (optional) — the arguments that should be passed to the component, in list or hash reference form. If none is given, no arguments are passed.
• compiler_params — this is a hash reference of parameters to be passed to the Compiler->new method.
• interp_params — this is a hash reference of parameters to be passed to the Interp->new method.
• interp — provide an HTML::Mason::Interp object to be used for the test.
• todo — if this is given, the test will be treated as a todo test, so it will be expected to fail. This should be a string.

okay so the doc says one of the following three options is required, and then lists four of them. not me noticing that 🙈 I'm just the messenger, the facts are the facts.

• expect — the text expected as a result of calling the component. This parameter is _not_ required when running in Create mode.
• expect_error — a regex that will be matched against the error returned from the component execution.
• no_warnings — if true, this means that the test expects to run without generating any warnings. If warnings are generated, the test fails.
• expect_warnings — a regex that will be matched against any warnings output when running the component.
• skip_expect — this causes the component to be run but its output is ignored. However, if the component execution causes an error this will cause the test to fail. This is used in a few situations where it is necessary to just run a component as part the preparation for another test.

🔥 run 🔥

run the tests in the group. that's it, that's the method. go off 💅

👑 Class methods 👑

these methods are provided since some tests may need to know these values. main character utility energy:

🌈 base_path 🌈

the base path under which the component root and data directory for the tests are created.

🧚 comp_root 🧚

returns the component root directory.

🍓 data_dir 🍓

return the data directory.

💜 check_output ( actual => $actual_output, expect => $expected_output ) 💜

given the parameters shown above, this method will check to see if the two are equal. If they're not equal, it will print out an error message attempting to highlight the difference. like a little diff detective 🔍

---

⭐ ADDITIONAL RUN MODES ⭐

the following additional modes are available for running tests. pick your fighter ✨

🗣️ Verbose mode 🗣️

to turn this on, set the environment variables MASON_VERBOSE or MASON_DEBUG as true, or run the tests as 'make test TEST_VERBOSE=1'. In this mode, the "run" method will output information about tests as they are run. If a test fails, then it will also show the cause of the failure. so you actually know what went wrong, obsessed.

🐛 Debug mode 🐛

to turn this on, set the MASON_DEBUG environment variable to a true value. In this mode, the "run" method will print detailed information of its actions. This mode includes the output printed in VERBOSE mode. it's giving maximum yapping, and honestly? needed.

🧼 No cleanup mode 🧼

setting the MASON_NO_CLEANUP environment variable will tell the module to not clean up generated data from running the tests. This includes the components written to disk and the data directory used during testing. This can be useful when debugging. (yes, the mess stays. it's on purpose.)

🪄 Create mode 🪄

if the individual tests are run from the command line with the '--create' flag, then instead of checking the output of a component, the test harness will simply output its results. This allows you to cut and paste these results back into the test file (assuming they are correct!). 😭 bestie, verify before you paste, that's all I'm saying.

🎯 Running and/or skipping selected tests 🎯

you can run just some of a test file with the '--tests-to-run' flag or the MASON_TESTS_TO_RUN environment variable. Similarly you can skip specific tests with the '--tests-to-skip' flag or the MASON_TESTS_TO_SKIP environment variable.

The value of either flag is a comma-separated list of one or more of

[test_file_name:](test_number|test_name|*)

e.g.

perl ./01-syntax.t --tests-to-run=3,5
MASON_TESTS_TO_SKIP=fake_percent,empty_percents perl ./01-syntax.t
MASON_TESTS_TO_RUN="misc:autohandler, request:*, interp:private1" make test

🧬 Subclassing this module 🧬

you can run tests with your own Tests.pm subclass using the '--tests-class' flag or the MASON_TESTS_CLASS environment variable. The value is a fully qualified package name that will be loaded before each test file is run. e.g.

perl ./01-syntax.t --tests-class=HTML::Mason::Tests::MyTests
MASON_TESTS_CLASS=HTML::Mason::Tests::MyTests make test

For example, if you have created your own lexer subclass and want to make sure that tests still pass with it, create a Tests subclass that overrides the _make_interp method to use your subclass:

sub _make_interp
{
    my ($self, %interp_params) = @_;

    return HTML::Mason::Interp->new
        ( lexer_class => HTML::Mason::MyLexer,
          %interp_params );
}

---

and that's the whole page, bestie!! 🫶 this was HTML::Mason::Tests, shipped as part of perl v5.38.2, dated 2024-03-05. now go write some tests, the harness has your back 💖✨🎀