|
|
Log in / Subscribe / Register

Semi-closing a hole

Semi-closing a hole

Posted Apr 12, 2012 8:55 UTC (Thu) by man_ls (guest, #15091)
In reply to: Semi-closing a hole by willmo
Parent article: Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 security release

My tests are working fine, thanks for your concern. They will even continue working after this update, as the Python devs have acknowledged the use case (while deprecating it but still).

Let me give some details about my approach. My test suite is dead simple: simply a bash script that runs the Python program against a predefined collection of test documents. For each one it generates the result file and compares (using plain old diff) this result with a pre-generated correct file. No output means that the result is correct. If there is any justified change in the code, I just mv the test file to the correct file. It is fast and works great, but it does not allow for runtime munging of dict keys.

In my program sometimes (not often) elements are output in hash order. If runtime hash generation was random I would have to output elements always sorted, which would penalize performance without any user-visible gains. But I would prefer having to sort everything than changing my test suite. And I would prefer not to change element output order unless it was strictly necessary.

I am not complaining about the change in the Python runtime because it invalidates my testing techniques, but I worry about possible side-effects: someone running the test suite on their machines with PYTHONHASHSEED=random and seeing failures would have a hard time diagnosing these failures. Just one more pain point for Python development.

One of the principles of Test-Driven Development is "do the minimal thing that passes the tests". I do not fully agree with it, but it can be useful sometimes. And especially when writing tests!


to post comments

Handling variability in test outputs

Posted Apr 12, 2012 9:57 UTC (Thu) by copsewood (subscriber, #199) [Link]

The testsuite I develop as part of PyLETS also has various hacks to cope with test results generating different files or strings than expected and still being valid results. E.G. auto-generated passwords, session cookies, date/time strings and related numeric values, URLs based on where the program is installed, and a growing list of other things. The approach my suite adopts is to normalise all of these values by using regexes and symbolic substitutions in both the expected stored values and actual values to replace variable expected values with symbolic constants prior to diff comparing actual against expected strings and files.

So I would also tend to regard this kind of breakage caused by an upstream dependancy as being the kind of thing I would expect to have to fix myself anyway in the course of upgrading the testsuite between major Python versions. Certainly wouldn't want the security of my application to depend upon whether I'd read and understood all the release notes of thousands of packages which run on my server.

Semi-closing a hole

Posted Apr 12, 2012 23:29 UTC (Thu) by joey (guest, #328) [Link] (1 responses)

Your tests are .. well, let's not say broken, let's say "fragile". Fragile tests are bad because they make it harder to make valid changes to the code of a program.

Semi-closing a hole

Posted Apr 12, 2012 23:34 UTC (Thu) by man_ls (guest, #15091) [Link]

You are probably right, but still I don't see an easier way to test what I want to test. Just an excuse for my own lack of imagination, I know. Oh well.

Semi-closing a hole

Posted Apr 13, 2012 0:50 UTC (Fri) by mgedmin (guest, #34497) [Link] (1 responses)

Are you aware that string hashes differ on 32-bit and 64-bit machines? A test suite that only passes on one particular CPU architecture is a broken test suite, in my book.

Semi-closing a hole

Posted Apr 13, 2012 20:03 UTC (Fri) by man_ls (guest, #15091) [Link]

You are probably right. In that case I don't see how the Python tests referenced above can work on 32-bit and 64-bit machines.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds