davies has asked for the wisdom of the Perl Monks concerning the following question:

A friend has written (in PHP - I'm trying to lead him to the light) a web site for backgammon clubs. He says it's about 10K lines and has no test suite. We found a bug some time back which he now claims to have fixed. The problem according to him was "a race condition between loading the page and loading its CSS". How might one go about writing tests for race conditions, whether in Perl or any other language? I don't see anything in Langworth & chromatic's book.

Regards,

John Davies

  • Comment on [OT] Testing race conditions in web pages

Replies are listed 'Best First'.
Re: [OT] Testing race conditions in web pages
by Corion (Patriarch) on Dec 04, 2018 at 14:08 UTC

    When testing for absence of specific race conditions (of whatever kind), I would try to eliminate the "race" part and instead slow everything into discretes steps that then get permuted. This makes the test casses reproducible, but isn't as easy as it sounds because you need to restructure your code so the racing parts become separately callable steps.

    If I assume the following structure (and error /race situation):

    1. User logs in on /login
    2. Session gets marked as "logged in" and the user account gets added to the session in the database
    3. User/session-specific CSS gets requested from /user/css
    4. User/session-specific CSS gets generated according to the session information from the database

    ... then, with the knowledge that we have a race condition, it's not hard to imagine the race happening somewhere between steps 2 and 4.

    To reproduce the error, it will be convenient to be able to permute these steps for the tests, so these steps should be callable somehow.

    Ideally, we don't need to stuff a session into the database just to retrieve it again, so I'd like to be able to optionally pass premade session information into the CSS generation. This should allow us to test whether stale information in the session generates correct CSS, at least in the case where we cannot control how quickly the database gets written to.

    Alternatively, an invariant to test for would be that the session has always been updated with the correct user before any HTML is output to the client. To make that possible, you will need to have separation between HTML output and session flushing so you can put your check there.

    Maybe you have more information about the race condition, then maybe we can suggest other approaches on where to cut the HTML generation, session updating and sending of the response...

[reply]
[d/l]
[select]
Re: [OT] Testing race conditions in web pages
by markong (Pilgrim) on Dec 04, 2018 at 14:12 UTC

    He says it's about 10K lines and has no test suite.
    Ouch, then I assure you there are some other bugs in your friend's game.

    "a race condition between loading the page and loading its CSS"

    ?? The browser accessing the website had the bug?

    Testing multi-threading programs is hard: some approaches are statistical, others play with timing...at the end you check that the shared program space (or shared variables) are in a consistent and expected state, plus you always go looking for some input --> output correct relationship.

[reply]
Re: [OT] Testing race conditions in web pages
by 1nickt (Canon) on Dec 04, 2018 at 14:04 UTC

    Hi, "a race condition between loading the page and loading its CSS" -- that doesn't make any sense to me. Even if the CSS is contained in an external file, it will be loaded as part of the page rendering by the browser, unless your friend is doing something very weird. 

    <html>
<head>
  <link rel="stylesheet" href="styles.css">
</head>
<body>

<h1>Hello, world</h1>

</body>
</html>

    [download]

    Tell him only PHP has that problem ....


    The way forward always starts with a minimal test.
[reply]
[d/l]

      I can easily imagine some dynamically generated CSS that depends on user settings. Getting a race condition in place in such a situation doesn't feel too far-fetched for me.

      Of course, you might consider dynamically generated CSS resources weird, but I don't think that that's a problem that would only occur with PHP.

[reply]

        Well. True, I haven't encountered dynamically-generated CSS, and I do think it is a little weird, but I suppose there are uses for such a technique. I was just kidding about blaming PHP, though!

        (edit: I have certainly manipulated CSS using JS, after page load ... and Corion reminds me that this very site generates CSS dynamically at least part of the time.)


        The way forward always starts with a minimal test.
[reply]

        Even if the CSS is indeed dynamically generated and user dependent, the race condition still makes no sense. Unless of course he's crazy enough to keep the URL of the CSS static and generate CSS for the last person that requested the page or something similarly insane.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

[reply]

Back to Seekers of Perl Wisdom