Home/ Questions/Q 7545191
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T08:51:54+00:00

The problem is: Manipulating external state in a test file reduces the possible parallelism

  • 0

The problem is:

Manipulating external state in a test file reduces the possible parallelism of your test suite.

What I’m testing is precisely manipulating external state (and then resetting it).

I’d still like to run in parallel most of the time. I’d then just like to skip the tests that would manipulate external state, which might make others fail.

So I would work around this problem by detecting the parallelism condition and then skip the test that would manipulate external state, thereby causing others to fail. Is that doable? How?

Note that just parsing the environment variable HARNESS_OPTIONS from your script isn’t sufficient to detect the condition: prove -j3, for instance, won’t set it.

Update

While there are lots of ways to let your test script know it’s being run in a parallel harness (see Brian’s answer below), there isn’t one standard way of doing so, which I thought there might be (but didn’t phrase this properly into my question).

I was thinking of something like, hmm, well, I read it in your (great!) Effective Perl Programming book, brian, something like maintainer tests, not sure of the term now, which you’d typically only run if you’re the maintainer of the module, not during installation on a user’s computer. Seem to remember there was a convention of using some environement variable for that.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The prove command creates the test harness object itself, so it passes arguments directly to the constructor of the test harness class (usually TAP::Harness). You don’t get to see those arguments.

    There are several ways you can go here:

    • Write a wrapper for prove to also set the environment variable if you use -j3.
    • Make your own subclass of Test::Harness to do the same if it gets the jobs argument and specify the subclass in your config for prove.
    • Don’t use prove (my favorite).
    • Use a semaphore from your test programs to note that another test program has control
    • Move the external interactions parts to a common library that can tell its callers if someone already has control
    • Many other things
    • 0